Category: Techstrong Council

Bridging the Dev–Security Gap With Smarter Authorization
Software teams have always lived with a built-in tension – developers push to ship fast, while security teams pump the brakes to assess risk. Now, with AI flooding the enterprise, that friction is spiking. One recent survey found a staggering 322% jump in privilege-escalation risks tied to AI-generated code. The root problem isn’t new – people and machines are routinely overpermissioned, and fixing it is notoriously hard. But the rush to adopt LLMs and autonomous agents is exposing just how dangerous overpermissioning has become. Real progress will require engineering and security to move in lockstep, starting with a smarter, shared approach to agent and LLM authorization.

That alignment requires security and development teams to jointly express, test, enforce, and audit authorization policies in real time, across both traditional applications and dynamic AI-driven environments. Instead of working in silos, they collaborate to determine who can access what and perform which actions across systems, APIs, and agents. This is the foundation of secure-by-design coding, and it’s essential for shifting a development culture in which 80% of companies knowingly ship vulnerable code, driven in large part by overreliance on AI-generated outputs that aren’t thoroughly vetted.

The Path Forward: Developer-First Security

Bridging the gap starts with technology that brings security directly into the development workflow without slowing it down. Instead of scattered, ad-hoc security checks buried across codebases and configuration files, when security and development teams align before generating code, they can approach security strategically, using a declarative approach that allows them to define their security, compliance, and data-protection policies in a single, structured format.

These policies can cover everything from access controls and encryption standards to audit requirements and data-retention rules. They become testable, traceable artifacts: developers can validate them locally, understand how each rule applies, and roll out updates safely using regression tests and automated validation. For security teams, this provides consistent, explainable enforcement across environments, replacing one-off reviews with reliable, repeatable checks.

Expanding to AI

For AI workloads, declarative security becomes indispensable because AI systems are probabilistic, not deterministic. They don’t follow fixed input-output patterns but generate novel behaviors, decisions, and data flows in real time. That unpredictability breaks the assumptions underlying traditional, rules-based security, which depends on predefined pathways, static access lists, and periodic audits.

In AI pipelines, each model inference or agent action can trigger new data movement, API calls, or external integrations that no engineer explicitly wrote. This demands runtime, context-aware enforcement – where policies evaluate who or what is making a request, what data is being accessed, and under what justification. Declarative policy frameworks make this possible by expressing identity, data-access, encryption, and audit requirements as machine-readable logic that can be versioned, tested, and automatically applied at runtime.

This shifts security from static guardrails to a living control layer that adapts to each model’s decisions, ensuring AI applications remain compliant, traceable, and safe – even when their outputs can’t be perfectly predicted.

Bridging Speed and Safety: Core Requirements for Secure Authorization

Overcoming the long-standing divide between developers and security teams requires tools that embed protection into the workflow itself. The goal is to combine modern development speed with consistent, auditable safeguards across distributed and AI-driven systems. To confidently run agents in production, the following requirements are the “gold standard”:
1. Automated Least-Privilege Access: Agents should receive only the permissions required for each task, with access adjusting automatically as context or behavior changes. The system must recommend reductions, temporary grants, or policy updates to continuously tighten access.
2. Anomaly Detection and Real-Time Alerting: Every tool call and data access must be captured. Security teams need actionable alerts on unusual activity so they can intervene before damage occurs.
3. Permission Controls and Agent Quarantines: Teams must be able to throttle agents, revoke tools, downgrade permissions (such as shifting to read-only), or quarantine an agent entirely with a single action when behavior seems unsafe.
These requirements transform a historic point of friction into common ground. Developers gain the confidence to move fast within clear, automated guardrails. Security teams gain the assurance that every decision is transparent, consistent, and compliant—whether in traditional applications or emerging AI pipelines.The result is that speed and safety advance together, with guardrails built in, not bolted on.

The challenge is no longer just building software quickly – it’s shipping it safely, especially when LLMs and autonomous agents can access sensitive systems and data at unprecedented scale. Under deadline pressure, organizations risk developers bypassing critical security practices to meet delivery timelines. But if development and security teams can work together to build right-sized, shared controls, they’ll no longer need to.
February 12, 2026
The Future of Infrastructure Automation in the Age of Autonomous Agents

For more than a decade, the evolution of infrastructure automation has followed a clear trajectory. Organizations have invested in workflows, pipelines, controllers, and compliance engines because the market demanded stronger guarantees around reliability and scale. Outages turned into measurable losses. Small misconfigurations cascaded into systemic failures. Even highly skilled teams struggled to keep pace with environments that grew more distributed, dynamic, and interdependent every year.

Today, the industry stands at a new inflection point. Autonomous agents have moved from intriguing prototypes to practical tools. They can interpret intent, evaluate operational conditions, and assemble multi-step plans that align with both policy and context. For the first time, AI can participate meaningfully in the operational lifecycle of infrastructure itself.

The central question has shifted. Enterprises are no longer debating whether AI will play a role in infrastructure operations. They are now focused on how to introduce it safely and predictably.

Three major shifts are already shaping this next chapter.

Shift One: Reasoning Is Moving Up the Stack

Historically, infrastructure automation has relied on rigid logic. Teams embedded rules, conditional branches, templates, and error handling directly into workflows. These constructs worked, but they required constant maintenance and could not easily adapt to new patterns or edge cases.

Modern language models and agent architectures are changing that dynamic. Instead of encoding every rule by hand, teams can rely on agents that understand natural language instructions, synthesize information across systems, and generate plans tailored to real operational conditions. This does not make workflows irrelevant. It changes their role. Workflows become the stable, trusted capabilities that agents call when they need precise, deterministic action. Planning shifts upward. Execution stays grounded in proven automation.

The result is a more flexible model that supports rapid adaptation without sacrificing consistency.

Shift Two: Deterministic Execution Becomes Essential

AI reasoning is inherently probabilistic. Infrastructure execution is not. As organizations explore how autonomous agents fit into their operational practices, they are discovering that the foundation still needs to be deterministic, governed, and transparent. Every action proposed by an agent must pass through strict schemas, policies, and permissions before it touches a live system.

In effect, AI can assist in creating the plan, but only a controlled execution layer should carry it out. This creates a clear boundary between suggestion and action. It also provides an auditable trail, enabling enterprises to scale their automation footprint without inviting unnecessary risk.

Safety and scale are converging on the same requirement. If AI is going to participate in operations, it must do so on top of an execution fabric designed to guarantee predictable outcomes.

Shift Three: Human-Machine Collaboration is Entering a New Phase

The relationship between operators and automation has always evolved. For years, the dominant model was human in the loop, where people approved or executed every significant step. We are now moving toward a more supervisory mode where humans oversee systems that handle routine execution. A better way to express this is that operators are moving into a monitoring and intervention role. They guide, steer, and correct rather than manually touch every action.

In certain domains, especially environments that require rapid response or operate at massive scale, the industry may eventually see cases where routine tasks operate with minimal human involvement. This is not about removing people. It is about reducing toil, shortening response times, and letting experts focus on strategic engineering work rather than repetitive tasks.

The goal is to raise the level of human contribution, not diminish it.

A Clear Trajectory Emerges

Taken together, these shifts point toward an ecosystem where infrastructure is supported by specialized autonomous agents, each designed for a specific domain and each operating within a governance framework that ensures safety, compliance, and consistency. Automation will not be driven by static playbooks alone. It will be driven by intelligent systems that understand context and rely on deterministic execution layers to perform the work.

This evolution mirrors what has happened in other complex systems. Manual processes gave way to scripted automation. Scripts gave way to orchestrated workflows. Now workflows are being augmented with reasoning capabilities that allow automation to operate at a higher level of abstraction.

The organizations that prepare for this shift will be the ones that gain the most operational leverage. They will move faster, reduce risk, and free their teams to focus on engineering rather than constant firefighting.

Autonomy is no longer theoretical. It is arriving in practical steps. Those who adapt now will lead the next era of infrastructure operations.

November 25, 2025
ClickOps, IaC and the Excluded Avocado Middle
Let’s start with a confession: I think Infrastructure-as-Code solves a lot of problems. Terraform, OpenTofu, Pulumi, all of it. IaC changed how we work. It gave us version control, audit trails, repeatability, and a level of discipline that the old “log in and click around” era couldn’t touch.

But somewhere along the way, we turned that discipline into a kind of dogma. We decided that most every infrastructure change needed to pass through the same elaborate ceremony designed for production, even if it was trivial, temporary, or experimental. Fast forward to today, and the result is that we’ve built a world where spinning up a quick dev environment can feel like applying for a mortgage.

As is often the case in the history of IT innovation, we solved one problem (chaos) and unintentionally over-rotated into another (rigidity). Between untracked ClickOps and full-blown IaC, there’s now a missing middle ground. I call it the deployment gap, and it’s the space between “move fast” and “don’t break anything” where much of real-world work actually happens.

Let’s peel the layers back on how we got here, why both extremes often are a poor fit, and then look at how a new class of intent-driven, policy-aware tooling can fill the void. Along the way, we’ll discover how the advent of LLMs and MCP has given us an opportunity to expose the choice between ClickOps and IaC as a false dilemma, creatively illustrated as the missing avocado middle.

How We Got Here

Before IaC, infrastructure was a mess of manual clicks and shell scripts. You couldn’t reproduce environments, track who did what, or even be sure the thing running in prod was the same as the thing you tested last week. IaC fixed (almost) all of that. It gave us a shared language, a single source of truth, and the confidence that what’s in Git is what’s in the cloud.

Then GitOps came along and wrapped the whole process in automation and governance. Together, they became the gold standard for production workloads where rigor and traceability matter.

The trouble is that once you have a hammer this good, everything starts to look like a nail. Teams began treating every infrastructure change as if it were production-critical. Need to prototype a new service? Write the Terraform, configure the backend, manage state, wire up CI/CD, get approvals, apply. Even if you’re going to throw it away later this afternoon.

That process is fantastic for uptime. It’s terrible for experimentation.

Meanwhile, developers under pressure to move fast did what developers do: they found workarounds. A few console clicks here, a test bucket there, and you’re in business. It seemed harmless at first, until those one-off resources became orphaned, went unpatched, and got expensive. ClickOps re-entered the picture, quietly and at scale. We call it “unmanaged drift”. We call it “shadow IT”. We call it “brownfield projects”. And what it often is – is people doing their job circumventing the process that’s too tedious, or too difficult to follow. As I’ve been pointing out in some of my other writing – the best way to make people follow the process is to make it more difficult not to do so.

Either way, it’s an outcome that’s the worst of both worlds: fast work that’s untracked and slow work that’s over-engineered.

And the gap between our two extremes got wider.

The Two Extremes

To fix something, you first have to see it clearly. So let’s look at the ends of this spectrum: ClickOps vs IaC + GitOps.

ClickOps is what happens when someone just needs to “get something running.” It’s instant gratification: you click “Create,” and the cloud obediently complies. No syntax errors, no commits, no pipelines. It’s also invisible to your peers, ungoverned by policy, and forgotten the moment you close the browser tab.

Think of it like duct tape: it’s fine for quick fixes, but you don’t want to build your house with it. Every untracked resource adds drift, technical debt, and security risk. Yet the demand for speed that fuels ClickOps is legitimate. When you’re prototyping or debugging, the last thing you want is ceremony.

At the other extreme, Infrastructure-as-Code plus GitOps gives you safety, versioning, policy enforcement, and collaboration. It’s the right choice for anything long-lived or business-critical. But it comes at a cost.

IaC is not just a syntax; it’s a well-developed ecosystem. You need to understand the DSL, the providers, modules, state management, policy engines, and CI/CD. Even for seasoned engineers, the overhead can be heavy. For newcomers, it’s a barrier.

GitOps adds more rigor (approvals, pipelines, reviews) but also more latency. For production, that’s exactly what you want. For a developer who just needs a sandbox to test a feature, it’s like using a cargo container to deliver a pizza.

So, we’ve arrived: at one end, you get velocity without governance, and at the other you get governance without velocity. Both extremes suck when you just want to build.

Filling the Gap: Intent-Driven Infrastructure

What’s missing is a lightweight, governed workflow that bridges speed and safety. Think of it as intent-driven infrastructure: a minimal translation layer between human intent and cloud resources.

The core idea is simple: when I say, “I need a small EC2 instance running Ubuntu,” I shouldn’t have to express that intent as 50 lines of HCL just to get something spun up. That doesn’t mean we abandon rigor. It means that we let the machine handle translation while keeping state, policy, and audit intact.

In an intent-driven model, you describe what you want in plain language via an LLM. The system interprets that intent, applies guardrails, and talks directly to your cloud provider’s APIs. It maintains a known state of what exists, complete with audit history. And when you’re ready for production, you can export that setup into Terraform or your IaC of choice. No YAML, no pipelines, no risk of “rogue” resources. Just speed, but now, with guardrails.

Guardrails Over Gates

One of the big lessons from the DevOps movement is that process gates slow people down, while guardrails keep them safe.

That’s an important distinction. Guardrails are constraints that keep you within safe boundaries while letting you move freely. In an intent-driven world, guardrails look like:
- Policy-as-Code enforcement: No public EC2s, no open S3 buckets, no expensive instance types.
- Session locking: One active session per project to prevent conflicting changes.
- Approval prompts for destructive actions: “Are you sure you want to delete this resource?”
- Drift checks and audit logs: So you always know what changed, by whom, and when.
These aren’t heavyweight governance tools. A more apt analogy is seatbelts. You don’t notice them until you need them, and when you do, they save you (and your cloud bill).

The Lifecycle of an Idea

Let’s map this to a real-world lifecycle.
1. Prototype: A developer describes an environment: “Spin up a t3.micro instance with a private IP and attach a policy.” A few minutes, and it’s deployed. The system records what it created and ensures it follows policy.
2. Experiment: The team iterates. Maybe it adds a database or a load balancer. Everything is tracked in state, and changes are auditable.
3. Promote: Once the concept stabilizes, the environment is exported to IaC. Now it joins the regular GitOps pipeline with full review, versioning, and long-term ownership.
4. Clean up: Ephemeral resources are destroyed automatically or on demand, avoiding orphaned costs.
This lifecycle preserves the best of both worlds, where you can finally get fast feedback loops early, but also strong governance later.

The Pressure Making this Idea Necessary, Now

Two forces are converging to make this middle ground essential.

First, AI is shortening feedback loops everywhere. Developers can already prompt a coding assistant to generate app scaffolding in seconds. If infrastructure lags behind, it becomes the new bottleneck. Intent-driven models bring infra up to the same conversational pace without abandoning control.

Second, organizations are under pressure to balance agility and compliance. Security teams can’t afford untracked shadow infrastructure, but they also can’t realistically gate every experiment. A policy-aware, auditable system lets both sides get what they need.

In other words, it’s not about moving fast and breaking things. Rather, it’s about moving fast within guardrails.

Reality Check

Let’s be honest about a few things we tend to gloss over. First, most environments aren’t production. We spend enormous effort on rigor for systems that will live a day or two. That’s wasted energy. Second, speed isn’t reckless—it’s context-dependent. The right level of process depends on the lifespan and risk of what you’re building.

And for what it’s worth, ClickOps isn’t evil. It’s a symptom of a bigger problem. When people click around in the console, they’re telling you your process is too heavy. Listen.

The point is that IaC isn’t the endgame. It was a brilliant step, but it turns out it’s not the final, canonical form of infrastructure management. In many cases describing intent may effectively replace authoring configuration.

Toward a More Human Infrastructure

The longer I work in this space, the more convinced I am that infrastructure shouldn’t feel like programming a compiler. It should feel like collaboration: I express what I need, the system translates it safely, and I stay in control.

That doesn’t mean abandoning code or pipelines. Instead, it means graduating ideas through the right levels of rigor at the right time. We’d use intent-driven workflows for what’s temporary, IaC for what’s durable, and ClickOps for… well, ideally we’d never use ClickOps again.

Another take is to consider that the future of infrastructure isn’t just more YAML. It’s fewer reasons to write YAML in the first place.

Infrastructure-as-Code gave us order. Intent-driven models will give us balance. Because sometimes, you don’t need a hammer or a screw, you just need to build something without smashing your thumb.
November 13, 2025
Learning From the Past: What Automation Mistakes Can Teach Us About AI

Across industries, organizations are rushing to embed AI into their operations. In fact, 84% of organizations are looking to add more AI capabilities within the next three years. From customer service bots to AI copilots, the future is arriving faster than many expected. But in the rush for quick wins, many executives are overlooking a hard truth: the pattern is a familiar one. The same pitfalls that plagued past automation efforts are re-emerging, and we’re at risk of repeating the same costly mistakes.

From rigid first-generation Business Process Management (BPM) tools to Robotic Process Automation (RPA), the root problem was the same: automation in isolation. Siloed tools, brittle logic, and a lack of orchestration turned many automation solutions into long-term liabilities and sources of technical debt.

If we’re not careful, AI threatens to repeat those mistakes—at scale, in real time, and under increasing regulatory and customer scrutiny. Here are three of the biggest automation mistakes, and how to avoid them in the future with AI.

1. Chasing Quick Wins

Any automation technology pitched as a fast track to results should come with a word of caution. For example, in the past, RPA promised to automate repetitive tasks with minimal IT involvement. While some use cases delivered short-term time savings, many programs failed to scale. All too often, RPA bots ran in departmental silos, with no end-to-end visibility or centralized control.

The problem? Technologies like RPA need orchestration. Without it, they become tactical—brittle, reactive, and hard to govern. As a result, many IT teams struggle to maintain the very systems that claim to be hands-off.

2. Automating in Silos

Automation silos remain a common problem across many organizations. In the early days of automation, different teams deployed different tools for different tasks—RPA in operations, iPaaS in customer support, legacy BPM in finance—each addressing local inefficiencies. But without a shared business process architecture or governance, these initiatives rarely worked together.

The result was operational inefficiency or processes that broke down altogether. When change inevitably hit—like a regulatory update or a system migration—every “island” had to be reconfigured independently.

The lesson? Automation that doesn’t scale across the enterprise ultimately won’t work. AI is no different. Without a central orchestration layer connecting people, systems, devices, and emerging technology like AI agents, automation remains a fragile patchwork.

3. Starting with Rigid Foundations

During the BPM wave of the early 2000s, many organizations focused on documenting how work should happen. However, the BPM tools these organizations adopted locked them into rigid business processes, which ultimately couldn’t adapt to changing needs.

That rigidity became a barrier. When teams needed to launch a new product, shift a customer journey, or respond to new regulations, they often had to rework entire business processes from scratch. Similarly, if AI tools can’t evolve with your business, they become liabilities—failing to scale, breaking under change, or introducing risk.

The better path forward is composable and dynamic. Processes should be modeled, but also executable. AI agents should operate inside adaptable business process modeling and design frameworks that support governance, transparency, flexibility for AI-based decision-making, and continuous improvement.

Avoiding Past Automation Mistakes in the AI Era

The pattern in all of these examples is clear: automation in isolation is fragile. AI is no exception.

Avoiding these historical issues means integrating AI into orchestrated, observable, and governable business processes from the start. We’ve seen what happens when automation is deployed without coordination—systems become harder to maintain, outcomes less predictable, and change more expensive. These failures were architectural, not due to a lack of ambition or investment.

To ensure AI delivers on its promise, we need to apply those hard-earned lessons proactively. That starts with treating AI as a participant in a broader business process architecture—one that’s modeled, orchestrated, adaptable, scalable, and governed.

Orchestration brings order to the complexity of AI-enabled operations. It connects human tasks, technologies, and AI into an end-to-end business process. It allows teams to observe what’s happening across the process, understand why AI made a particular decision, and step in when needed. Most importantly, it provides the guardrails that fast-moving, high-risk technologies like AI demand.

Without orchestration, AI is just another isolated tool that can be prone to failure, difficult to manage, and disconnected from the outcomes that matter. With orchestration, it becomes something else entirely: an intelligent, integrated part of how work gets done.

If we want AI to scale beyond prototypes and pilots, to operate safely and strategically across the enterprise, we can’t afford to make the same mistakes. We need to learn from them and make orchestration the default, rather than an afterthought.

November 10, 2025
Securing the AI Era: How Development, Security, and Compliance Must Evolve
The Code Boom and Its Paradox

We are witnessing an unprecedented shift in how software is built. With the rise of AI copilots, automated agents, and low-code platforms, code is being produced faster than at any point in history. What once took weeks can now be generated in minutes.

This is a remarkable advance, but it comes with a paradox. The explosion of code does not guarantee that software is more secure. In fact, the opposite is often true. More code increases the attack surface. AI introduces unpredictability and novel risks. Traditional approaches to securing the software development life cycle (SDLC) cannot keep up.

The core question for engineering and security leaders is no longer just how to build software quickly, but how to ensure that the speed of development is matched with the strength of security.

Maker and Checker: A Model That Must Evolve

Historically, software relied on a clear separation of roles. The developer was the maker, building features and writing code. The security analyst was the checker, reviewing work and catching mistakes before deployment.

This principle of dual control worked in a world of deliberate, slower releases. But in an AI-accelerated SDLC, it breaks down. The checker cannot keep pace with the volume of AI-generated code. Manual approvals and reviews become bottlenecks. Teams are forced to choose between velocity and safety.

The answer is not to abandon the maker and checker model. It must be rewired. Instead of gates that block progress, security becomes a set of guardrails. Developers are empowered with real-time feedback, while security engineers build the systems that enforce policy at scale.

The Developer’s New Role

Developers are no longer just authors of code. They are curators, reviewers, and defenders. Their responsibilities have expanded in three ways:
1. Curators of AI Output: Evaluating and integrating machine-generated suggestions, rejecting those that are insecure or opaque.
2. First Line of Defense: Operating with guardrails embedded within Integrated Developer Environments (IDEs) that flag unsafe code immediately.
3. Security-Aware Makers: Building features with an understanding that functionality and safety are inseparable.
The developer’s role is not to become a full-time security engineer, but to be empowered with guardrails and secure defaults that make the secure path the easy path.

The Evolution of Security Roles

The roles of security analysts and engineers must evolve as well. Analysts can no longer simply triage alerts and file tickets. Engineers cannot spend their time patching vulnerabilities one by one.

The future role is the Security Automator. Analysts become risk-ops engineers who tune signals and build dashboards that highlight the most important issues. Engineers become platform builders who embed policy-as-code and guardrails into the SDLC. Together, they design systems that intercept risks, automate remediation, and scale security across hundreds of developers.

Security is no longer about catching flaws at the end. It is about building systems that prevent flaws from being introduced in the first place.

The SDLC Becomes a Continuous Risk Loop

The linear SDLC is dead. The traditional flow of design, build, test, release, and operate no longer fits the reality of AI-driven development. Code is written and deployed continuously. Risks emerge at any point in the cycle.

The modern SDLC must be reimagined as a continuous risk loop.
1. Build: Code is produced by humans and AI.
2. Intercept: Guardrails catch issues in real time.
3. Triage: Risks are prioritized based on context and exploitability.
4. Remediate: Fixes are suggested or applied automatically.
5. Govern: Security and compliance teams ensure that these processes are aligned with organizational standards.
This loop is not theoretical. It must run continuously with every commit and every deployment.

Product Security 2.0: From Policies to Platforms

Product security has traditionally lived in documents and checklists. Policies are written, reviews are scheduled, and compliance evidence is gathered manually.

That approach cannot handle the speed of AI-driven software. Product security must shift from policies to platforms.
- Policies must become code that runs in pipelines.
- Guidelines must be replaced by guardrails that operate in IDEs and CI/CD.
- Evidence must come from dashboards that pull data directly from automated controls.
Product security becomes an engineering discipline. Its output is not documents, but systems that enforce security continuously and automatically.

Compliance That Improves Security

Compliance has long been viewed as a checkbox exercise. Audits are passed, but attackers do not care about certificates. Compliance alone does not prevent attacks.

Recent frameworks are changing that dynamic.
- PCI DSS 4.0 now requires organizations to manage all vulnerabilities, not just those rated critical.
- NIST SSDF emphasizes embedding secure practices throughout the SDLC.
- NIST CSF 2.0 added Govern as a new core function, making governance and accountability central to security.
These frameworks push organizations toward continuous, risk-driven security practices. Done correctly, compliance can become a forcing function for real security.

Metrics That Matter in the AI Era

Speed without safety is a false victory. Traditional metrics such as deployment frequency and mean time to recovery (MTTR) are not enough. Organizations must measure how well they manage risk at AI speed.

Key categories of metrics include:
- Detection: Mean time to intercept unsafe code, percentage of vulnerabilities caught pre-commit.
- Remediation: Mean time to remediate vulnerabilities, percentage of issues auto-remediated.
- Coverage: Percentage of repos and services protected by guardrails, policy drift between declared and enforced rules.
- Risk Reduction: Reduction in exploitable vulnerabilities, time to safe after each release.
The most effective organizations blend DORA metrics with these security metrics. This provides a holistic view of both velocity and safety.

A Call to Action

The AI era has redefined software. It has also redefined security. Developers are curators and first defenders. Security analysts and engineers are system builders and automators. The SDLC is a continuous risk loop. Product security has shifted from policies to platforms. Compliance frameworks are pushing organizations toward continuous, risk-driven practices.

The organizations that will thrive are those that measure not just how fast they can ship, but how safely they can ship.

The challenge is clear, and so is the opportunity. By embracing continuous guardrails, automation, and governance, we can ensure that software in the AI era is not only faster, but also stronger and more secure.
October 28, 2025
Infrastructure as Code, Security Blind Spots, and the Messy Reality of DevOps

I’ve spent most of my career in infrastructure and reliability engineering, from years as an SRE at Google to leading teams at Facebook and now building Spacelift. Along the way, I’ve watched entire paradigms rise and fall, seen technologies mature, and learned some hard lessons about where DevOps and security meet—and where they clash.

The interesting thing is that despite all the noise, infrastructure as code (IaC) hasn’t really changed in a decade. Terraform and CloudFormation are still the foundations. Yes, new features get added, and yes, we now have layers of automation, wrappers, and commercial tooling, but the core workflow remains constant. That stability isn’t a weakness; it’s actually a strength. It means the skills you build are transferable across jobs and organizations, unlike in front-end development where the framework of the week can make yesterday’s expertise obsolete.

But stability doesn’t mean simplicity. The reality in most organizations is far messier than the marketing slides suggest. There is no linear progression from one technology to the next; instead, you find overlapping eras, conflicting tools, and processes that look beautiful on paper but fall apart in production. And when you add security into the mix, the friction becomes obvious.

The Ceremony of Audit

Let’s start with audits. In theory, audits are supposed to strengthen organizations by identifying weaknesses and validating controls. In practice, they often turn into ceremonies. Think of it as a school play: no one enjoys it, but everyone goes through the motions because regulators and customers demand the certification.

If your organization isn’t already in a decent place, audits don’t teach you much. They just become processes written for auditors rather than engineers. I’ve seen countless cases where teams follow the letter of the audit process while ignoring the spirit. People fix problems quickly under pressure, then backfill paperwork later to make it look like the official procedure was followed.

This doesn’t mean audits are useless. When teams have trust and good communication, audits can provide genuine learning opportunities. But to get there, the gap between stated policies and reality has to be small enough that findings are actionable rather than overwhelming.

Security Processes vs. Human Behavior

Security teams often design processes that are logical, comprehensive, and compliant—yet completely impractical when the production deployment is burning down at 3 a.m. on a holiday weekend. Humans under stress take the path of least resistance. If the secure path is the easiest path, people will follow it. If not, they’ll bypass it.

This is the reason why so many DevOps and security teams end up at odds. The security processes are optimized for auditors, not operators. In truth, procedures aren’t just about compliance. They’re also job insurance. If you can point to the plan you reviewed and the checklist you followed, you’re protected even if production still went down.

But the only way processes consistently work in real incidents is if they are simple, automated, and designed with the operator in mind.

Automation as a Lifeline

Humans are terrible at multitasking, yet incidents demand juggling multiple priorities. That’s why automation matters so much. Offload what you can to machines, whether it’s incident coordination, credential rotation, or infrastructure workflows. Automation doesn’t just reduce toil; it makes the secure way the easy way. If obtaining temporary credentials requires six approvals and three logins, people will find workarounds. If a tool can handle the process in seconds, suddenly compliance isn’t painful.

We’ve built flows that make secure operations simple, because the alternative is predictable, and usually looks like engineers doing “infra archeology,” trying to reconstruct what’s really running in production after drift and ad hoc fixes have accumulated. We’ve also built a new tool that makes it trivial to turn your day two operations into proper products.

Infra Archeology: When You Don’t Know What’s Running

The aforementioned infra archeology is what happens when your version control history no longer matches your production reality. Maybe someone ran Terraform locally and never checked in the code. Maybe hotfixes were applied manually. Maybe no one even remembers who owns a particular service.

I saw this at Google, where the rule was “if it isn’t checked in, it isn’t in production.” But rules without enforcement don’t hold. Eventually, sometimes the only way to figure out what a service did was to shut it down and see whose pager went off and why. For today’s IaC, I believe strongly in enforcing version control. If infrastructure changes aren’t checked in, they don’t run, period. Customers sometimes ask for exceptions, but for every one legitimate case, there are 99 that would turn into security nightmares. A strict stance saves everyone from painful archeology later. Infrastructure management of tomorrow may not have the same constraints but until it arrives and matures. I’d suggest that your production environment and Git become best buddies.

Context Is Everything in Logging

Another frequent blind spot is audit logging without context. It’s not enough to know that an API call was made at a certain time by a certain role. Without context, you end up playing detective, trying to guess intent from timestamps.

What’s really needed is the ability to backtrace from an API call all the way to the human and reason behind it. You need the run ID, the code version, the pull request, the JIRA ticket, the approver. That kind of chain transforms logs from raw data into an explanation of “why.” Without it, all you know is that something happened, and that’s almost useless.

The Dangers of What You Don’t See

Security professionals often over-engineer the visible parts of their systems while ignoring hidden weaknesses. I’ve seen AWS accounts locked down with meticulous IAM policies, only to be blown wide open by a vendor that required a single unscoped API key for programmatic access.

The biggest risks usually come from what you don’t see: shared credentials in Zapier, secrets passed around Slack, or third-party tools with poor credential hygiene. Those blind spots undermine months of careful architecture.

This is why eliminating static credentials and adopting federated identity is so important. Federated identity systems (like OIDC) remove the need for long-lived keys, yet adoption is slower than it should be simply because many engineers don’t know the concept exists. Awareness is the first step.

Policy as Code and Its Limits: Keep it Simple

Policy as code is a valuable tool, but it’s not a silver bullet. It acts as a force multiplier, enforcing guardrails and preventing obvious mistakes. But no tool replaces understanding. A policy written without comprehension is just another box to check. This applies broadly: whether you’re using Vault, IAM roles, or federated identity, you need to understand the underlying principles. Otherwise, you’ll miss the bigger risks—like vendors whose APIs are fundamentally insecure.

Complex processes invite workarounds. Beautifully designed procedures often fail because real humans don’t have the time or patience to follow them under stress. Every backdoor someone creates to bypass complexity becomes a permanent vulnerability. So, the lesson is, don’t overcomplicate. Design processes that humans will actually use. Favor simplicity, clarity, and automation over ceremony and bureaucracy.

Where AI Fits

Like every other tool, AI is another force multiplier. It can help validate assumptions, suggest optimizations, or flag anomalies. But it won’t save you if you lack the basics. It’s like using a phrasebook in a foreign country, where you might ask the question correctly, but if you don’t understand the answer, you’re still lost. AI won’t replace the need to learn security fundamentals.

Small Wins for Teams

Where should teams start? First, learn the concepts. Read the HashiCorp Vault manual. Understand why static credentials are dangerous. Learn how federated identity works. You’ll also want to eliminate static credentials everywhere you can. Even small steps (like replacing one API key with a scoped role) reduce risk. And keep it simple. Specifically, avoid ‘security theater’. Build processes that are usable in real-world stress.

Also, with regard to AI, automate wherever you can. Let machines handle toil so humans can focus on judgment. Finally, when it comes to vendors, pay attention. Your posture is only as strong as your weakest link. Don’t let someone else’s bad API design become your backdoor.

The Human Factor

At the end of the day, security is about people. Engineers under pressure won’t follow processes that are cumbersome or incomprehensible. Leaders who design systems must respect human limitations. Attention is the scarcest currency in technology.

The job of anyone building infrastructure, platforms, or security is to make the secure path the easiest path. If it isn’t easy, it won’t be followed.

That’s the messy reality of DevOps and security. Not a clean progression of tools, but a patchwork of systems, shortcuts, and trade-offs. Success doesn’t come from ceremonies or checklists; it comes from building processes that work for humans as well as auditors.

October 17, 2025
The EU’s Cyber Resilience Act: Redefining Secure Software Development
The European Union’s Cyber Resilience Act (CRA) marks a turning point for anyone building, selling, or maintaining digital products. Whether it’s enterprise software, consumer apps, IoT devices, or embedded systems, the CRA sets rigorous cybersecurity requirements that apply throughout a product’s entire lifecycle, from design and development to deployment, maintenance, and secure decommissioning.

At its core, the CRA is about security-by-design. It mandates transparency, robust vulnerability management, and secure updates backed by enforcement mechanisms such as CE marking, machine-readable Software Bills of Materials (SBOMs), and compliance documentation.

Why You Need to Start Now

The CRA fundamentally redefines how software will be built and maintained, pushing organizations to adopt more structured, transparent, and security-centered development strategies. And if you’re like most commercial software developers who incorporate open source components, you’ll need to account for your dependencies. Your team will need time to adapt development and security workflows to meet these new expectations.

The timeline for CRA compliance is already in motion:
- December 2024 – The CRA came into force. This marked the start of the transition period for all affected stakeholders.
- September 2026 – Early obligations take effect, including mandatory vulnerability reporting to EU authorities, specifically the European Union Agency for Cybersecurity (ENISA).
- December 11, 2027 – Full enforcement begins. By this point, stakeholders must be ready with machine-readable SBOMs, secure update mechanisms, and detailed compliance documentation for every applicable product.
And, it’s important to note that the consequence of non-compliance isn’t just a fine. It can mean being locked out of the EU market entirely.

Roles and Responsibilities Under the CRA

Before we jump into the actual impacts of these regulations, let’s take a moment to clarify the different roles and responsibilities in the software development process. In its latest iteration, the CRA clarifies distinct roles and who’s accountable within the open source ecosystem:
- Manufacturers: Any entity placing a product (including those built from OSS) on the EU market. They bear full legal responsibility for security throughout the software lifecycle.
- Open Source Stewards: Newly defined economic actors, such as those who systematically support an open source project as a sustained offering intended for commercial use.
- Maintainers/Contributors: Individuals or teams engaged in development. Generally, they are not directly bound by CRA obligations, unless acting as stewards or manufacturers.
This structured distinction allows the CRA to exempt casual contributors while focusing legal accountability on downstream producers. However, even though maintainers may not face direct enforcement, the realities of dependency chains mean they must adapt. For example, many manufacturers will insist on robust security hygiene, transparency, and responsiveness from upstream projects. As a result, maintainers will find themselves needing more structured workflows, clarity on vulnerability handling, and easier collaboration pathways.

Specific Obligations for Organizations Building Software

Clearly, manufacturers face the greatest burden in this scenario. But what exactly are they responsible for? Under the CRA, manufacturers of all sizes, including software publishers, must:
- Generate a machine-readable SBOM listing, at a minimum, top-level dependencies.
- Keep SBOMs updated and provide them to market surveillance authorities upon request.
- Maintain vulnerability handling frameworks, including having a public channel for reporting and a quick remediation pipeline.
- Apply secure updates, ideally over-the-air, and separate them from functional updates.
- Share patches upstream for OSS components they use, fostering better ecosystem security.
Non-compliance with the CRA can come at a high cost. Fines may reach €15 million or 2.5% of global annual turnover, whichever is higher. Some responsibilities that were previously optional, such as sharing patches with upstream projects, are now required. This shift means organizations need to reassess how they handle compliance across the software lifecycle. That includes generating and maintaining SBOMs, securing CI/CD pipelines, improving vulnerability scanning, and strengthening patch management processes.

Impact on DevOps Teams

So, what does this mean, precisely, for those of us building new software? For DevOps practitioners, the CRA’s broad and deep mandates mean applying security across both processes and toolchains. DevOps teams will need to:
- Incorporate SBOM generation and management for all PDEs (Products with Digital Elements), continually updating them.
- Establish or enhance vulnerability disclosure mechanisms and incident reporting channels, including timely communication with relevant authorities such as ENISA.
- Ensure secure, streamlined software updates, preferably separated from feature updates, and automatic where feasible.
- Conduct software risk analyses, enforce code integrity (e.g., through signing), encrypt data streams, and maintain documentation for extended periods (up to 10 years or the product’s support lifespan).
These new requirements are pushing many organizations to modernize how they build and ship software. Instead of treating the CRA as just another checklist, forward-looking teams see it as a chance to strengthen security across the entire development process. That means improving how dependencies are managed, automating SBOM generation, tightening vulnerability response, and separating security updates from new features. When done well, these changes don’t just satisfy compliance requirements. They also reduce technical debt, improve long-term resilience, and help build trust with users and partners. In many cases, preparing for the CRA can be the push teams need to develop software that is more secure and easier to maintain.

Turning to the Community for Guidance

Few regulations have created as much industry-wide urgency for practical guidance as the CRA. Small- and medium-sized enterprises (SMEs) are particularly vulnerable, as they often lack the compliance resources of their much larger counterparts.

The good news: the industry is responding. The Open Regulatory Compliance (ORC) Working Group, hosted by the Eclipse Foundation, was created to develop actionable resources and collaborate with government agencies to help organizations comply with regulations, such as the CRA.

Backed by neutral governance, strong ties to standardization bodies (CEN, CENELEC, ETSI), and liaison to the EU’s CRA experts, ORC includes more than 50 members and is rapidly growing. This diverse group brings together global technology companies like Nokia, Mercedes‑Benz, Microsoft, Red Hat, GitHub, and Google, more than 20 open source foundations, and a growing number of SMEs working together on practical solutions.

This cross-industry, open source–friendly initiative is helping developers, enterprises, and open source communities navigate this evolving regulatory landscape with clarity and confidence. ORC provides a collaborative platform to share relevant resources, including specifications, best practices, and reference materials, and serves as a trusted forum for dialogue with regulators, standards bodies, and industry stakeholders. With its depth of expertise and commitment to open source values, ORC is uniquely positioned to shape a practical, balanced path to CRA compliance.

The Time to Act is Now

With the first CRA obligations taking effect in September 2026 and full enforcement by December 2027, the window for preparation is narrowing quickly. While some regulatory details are still being finalized, the direction is clear. Now is the time to align your development workflows, build compliance into your pipelines, and contribute to the broader conversation shaping how these rules will apply in practice.

ORC is one example of how the open source community is coming together to tackle these challenges collectively. By sharing resources, expertise, and practical tools, ORC is helping organizations of all sizes prepare for CRA compliance without sacrificing agility or innovation.

The CRA is more than just another set of rules. For DevOps teams and software professionals, it’s a chance to make security a built-in part of everyday work. This isn’t only about meeting legal requirements. It’s about helping shape a software ecosystem that’s easier to trust, easier to maintain, and better for everyone involved.
August 26, 2025
From Automation to Orchestration: The Key to Digital Success

Digital transformation continues to be a key focus for many organizations, and this usually means the automation of processes and data.

At its core, automation is meant to simplify and streamline business operations. However, if not implemented correctly, it can introduce complexity, risk and fragmentation. The proliferation of automation tools, combined with the rapid growth of interconnected systems has created a tangled web of interdependencies that are becoming increasingly difficult to manage.

In fact, recent research has shown organizations now manage an average of 50 endpoints to execute tasks that are part of a process in their business (this is a 19% increase over the past five years). Without a fundamental shift in approach, organizations risk becoming overwhelmed by digital chaos – what’s more, 82% fear they could find themselves dealing with ‘Automation Armageddon’ if processes are left unchecked.

Bringing Order to Automation Complexity

As automation becomes more ingrained, organizations are facing new operational risks that threaten efficiency, compliance, and agility. One of the biggest challenges is the sheer volume of interconnected systems and workflows that businesses now rely on. When it comes to process complexity, more than three quarters of organizations say that a lack of control has resulted in increased risk that core business processes are not working anymore.

At the same time, rising regulatory demands are making compliance more difficult. A lack of control has also increased business risk relating to compliance and many organizations lack the visibility to ensure compliance across all automated processes.

As automation scales, it becomes harder to gain insights into what’s working, what’s redundant, and where bottlenecks exist. This lack of visibility makes it difficult for leaders to drive continuous improvement and ensure automation is delivering real value.

AI: The Operationalizing and Scaling Challenge

Despite AI being at a relatively early stage in terms of widespread adoption, AI is already revolutionizing industries, enhancing decision-making, improving customer experiences, and driving efficiencies across business processes. Many organizations are eager to expand their AI capabilities, integrating machine learning models, predictive analytics, and AI agents to uncover new opportunities.

A significant challenge facing organizations is being able to operationalize and scale AI; 85% of organizations report such challenges, highlighting the difficulty of moving from isolated AI implementations to fully embedded AI-driven end-to-end processes. This fragmented approach makes it difficult for businesses to realize AI’s full value, as disconnected AI initiatives fail to work cohesively within larger business processes.

Another hurdle is governance and compliance. As AI becomes more embedded in decision-making, organizations need clear oversight into how models are trained, deployed, and maintained. Transparency is crucial, particularly in regulated industries where AI-driven decisions must be explainable and auditable.

To overcome these challenges, organizations must implement “guardrails” that combine deterministic workflows with the non-deterministic nature of AI capabilities. By clearly defining operational parameters, businesses can ensure AI operates autonomously while adhering to organizational policies and regulatory standards. This approach allows businesses to leverage AI’s adaptability and predictive power within structured, reliable processes without sacrificing compliance or control.

How AI Can Be Integrated

AI systems need to be seamlessly integrated into existing business processes to ensure they deliver real value. Without orchestration, AI often functions in isolation, requiring manual effort to synchronize with other process endpoints. This disconnect leads to inefficiencies and makes it impossible to “control” AI sufficiently.

Embedding AI within a structured orchestration framework provides clear governance and simplifies management – effectively balancing predictable, deterministic workflows with the adaptive, non-deterministic capabilities of AI, which are increasingly executed by one or more AI agents. Structured orchestration defines clear interactions between human and AI-driven tasks and delivers real-time visibility into operations. This reduces complexity, eliminates silos, and unlocks AI’s full potential as a strategic asset.

Process orchestration also enables organizations to build processes quicker with the help of AI, as modern orchestration tools can help teams in the process modelling phase. Furthermore, process orchestration allows organizations to gain insights into end-to-end processes in real-time and detect bottlenecks or other problems within an automated process. AI can then help to find solutions to solve the process issues, enabling businesses to optimize operations, improve decision-making, and scale AI usage effectively.

To fully leverage AI, organizations must move beyond ad hoc implementations and toward a strategic, orchestrated approach. This way, they can maximize efficiency, maintain compliance, and ensure that AI contributes meaningfully to broader digital transformation efforts.

Why Orchestration Helps Ensure AI and Automation Initiatives Play the Right Tune

To regain control, organizations must embrace end-to-end process orchestration as a core part of their business and IT strategy. Process orchestration and automation allows organizations to tame complexity, operationalize AI, and accelerate transformation. Organizations can design, manage, and improve the processes that underpin their business, no matter what the processes entail or where they run. Additionally, it serves as a critical link between IT and business teams, aligning automation initiatives with real operational needs and long-term business goals.

Automation Is Inevitable, But Chaos Isn’t

Automation without orchestration leads to fragility, not resilience. Those organizations that prioritize process orchestration will be those who turn automation and AI into a competitive advantage and avoid the looming threat of digital chaos or ‘Automation Armageddon’.

June 13, 2025
Managing Day 2 Concerns for Agentic AI Architecture
We’re now in the fifth wave of computing. If that sounds dramatic, that’s because it is—and probably also because someone in marketing really wants to make “agentic AI” stick. For those keeping track at home, the first four waves were mainframes (your granddad’s computer), web (when we were all hopeful), cloud (when we were still kind of hopeful), and mobile (where that hope became a subscription to your attention span).

And now? Agentic AI.

Let’s get the buzzwords out of the way: Agentic AI is a fancy term for giving large language models (LLMs) persistent memory, looping logic, and callbacks to reach out to your APIs. It’s like giving a Roomba a graduate degree and asking it to run your IT department. These “agents” operate independently (ish), have goals (ish), and make decisions (ish) based on prompts, semantic search and however much context you can cram into a vector database.

Sounds fantastic. Until you have to operate and maintain this stuff in production.

Because Day 1 is always a party, demos run great on slide decks. Day 2 is when the ops team walks into the room, sees the cloud bill, and quietly walks back out.

The Scale Problem (a.k.a. We Broke TPS)

Let’s talk about scale. Traditional systems had thousands to millions of users. With mobile, we got billions. Agentic AI? Try trillions. Not just people, though. You’ll have agents helping users, agents helping agents and agents judging the work done by other agents.

Mainframe

Web

Cloud

Mobile

Agentic

Users

thousands

millions

100 million

billions

trillions

TPS

100

500

2,500

10,000

1,000,000

5x

5x

4x

100x

Each one of those agents runs loops. Each loop makes calls. Each call hits an LLM. Every LLM call contributes to Transactions Per Second (TPS). Not all transactions or LLM interactions are the same. Humans have very different behavior than agents.

The types of interaction behavior we might see:
- Human users = finite and sleepy
- Agents = infinite and caffeinated
- LLM inference = expensive, slow, and shockingly unreliable
- Therefore: system load = Who knows? How do we even predict this stuff?
It isn’t unusual for pre-agentic systems to max out around 10,000 TPS. Agentic systems? You’re looking at a million TPS just to hit parity with your company’s Slack usage.

But What About Cost?

Ah yes, the CFO’s favorite section.

Running agents is expensive. Running smart agents is very expensive. Running smart agents 24/7 with high-accuracy LLMs? Welcome to a world where your annual AI ops bill might be an order of magnitude higher than it was before.

Let’s put that in relatable terms:
- GPT-4 32K (86% accuracy): $98 per million tokens
- Open source model (42% accuracy): $0.013 per million tokens
- Database transaction: pocket change by comparison
And don’t let the open-source optimism fool you. A 42% accurate agent might write emails like “Dear Sir/Madman, I have eaten the spreadsheet,” which is cute until it’s running your treasury. Remember that hallucinations and bad responses are so common, we already have patterns for using multiple other LLMs just to judge the work of the first. This means that your cost isn’t just the cost to ask an LLM an innocent question, it’s the cost to resolve tools, cost to make the actual request and cost to make potentially multiple judgment requests.

So now you’re faced with the AI version of the eternal tradeoff: dumb and cheap vs. smart and broke.

Latency, Reliability and Other Sad Stories

LLMs are not built for low-latency, high-throughput work. They’re built for… storytelling. And hallucinating. And sometimes – if you ask nicely and are an expert in prompt engineering – even answering your questions.

Now, imagine your core systems relying on that. Imagine your uptime metrics depending on the whims of an LLM inference API that thinks “return customer data” means “find a retail location where customers can bring and return their data”

Agentic systems aren’t transactional. They’re conversational. They’re unpredictable. They can fail to give you an answer, they can stop answering in the middle of a stream. Don’t listen to what people tell you, you can’t blindly trust an LLM.

And yet, we keep trying to run them like traditional software. We build orchestration platforms, routing layers, retry loops, and cost governors. Why? Because otherwise, these things will try to eat the entire internet in a single for-loop and send us the cloud bill.

Capacity Planning Is Now Chaos Planning

You used to think about load in terms of peak usage. Now? Your agents don’t sleep. They don’t go to lunch. They just keep going, looping away, slamming vector DBs and semantic search engines with relentless, existential enthusiasm. Your system lows are higher, your median times are higher, and your peaks are higher.

This means:
- Your database load goes up 100x
- Your network saturates under constant agent chatter
- Your infrastructure team turns into a stress-testing experiment
- And you still get worse answers than just asking the intern
You don’t plan for “peak load” anymore. You plan for “non-stop Reddit debates between bots.”

The Blueprint (Such as It Is)

In theory, building a sustainable agentic architecture looks like this:
1. Semantic Search – All your domain knowledge gets shoved into a vector DB, ready to be retrieved by semantic similarity.
2. Agentic Sessions – Every agent interaction is logged to provide context, continuity and accountability.
3. LLM Invocation Loops – Prompt, retrieve, augment, call LLM, process, repeat until you get a satisfactory answer, or you run out of usage quota.
4. Orchestration Layer – The puppet master that tells agents what to do, when, and for how long before they bankrupt you.
This is all manageable, assuming you can hire a team of distributed systems engineers who also speak fluent “prompt engineering,” understand vector math, and have no plans for sleep.

What Ops Teams Need to Do (Besides Cry)

If you’re serious about building something in this space—and not just gluing ChatGPT to your CI pipeline, you need to:
- Plan for real-time TPS: Millions of them, all at once, with unpredictable spikes.
- Plan for augmentation (RAG): Simple one-off queries are rare. Instead, your agents will be making multiple round trips to the LLM to resolve tools and multiple passes at a vector database for context augmentation.
- Instrument your agents: Know which model they’re using, how often, and at what cost.
- Design for failure: Assume models will hallucinate, APIs will fail and your agents will suddenly think they’re writing sci-fi.
- Stay modular: You’ll want to swap models faster than your CFO can say “cost optimization.”
Final Thought: The AI Agency Gap

The AI Agency Gap is the chasm between dumb bots and actual autonomous systems. It’s the space where most agents will live—semi-capable, semi-stable, semi-helpful. They’re the interns of the software world: energetic, inconsistent and always one bad prompt away from disaster.

If you want to thrive in this new wave of computing, you’re going to need resilience, observability, guard rails, patience and some really good stress coping techniques. The future isn’t just about building agentic systems, it’s about knowing that you’ve made all of your microservices unpredictable and require 10x more resources.

Good luck.
June 5, 2025
Hybrid Infrastructure Is a Mess—But It Doesn’t Have to Be

If you’re a CIO who is managing hybrid infrastructure, you’re like the peace-keeper in a dysfunctional family. On one side, you’ve got the old-school on-prem team—practical, cost-conscious, maybe a little stubborn. On the other hand, the cloud team is fast-moving, quickly adopting the latest tools, and sometimes a little dismissive of “legacy” infrastructure. And just like a family that doesn’t get along, they barely talk to each other.

I see this all the time. A CIO will tell me, “I need to unify my infrastructure strategy,” but when I speak with their teams, it’s like talking to two different companies. The cloud engineers don’t know (or care) what the on-prem team does, and the on-prem team sees the cloud people as reckless spenders who don’t understand “real” infrastructure.

Hybrid Isn’t Going Away—So We’d Better Get It Right

The thing is, both sides have a point. On-prem infrastructure is more predictable in cost, often more secure, and sometimes just makes sense for certain workloads. And the flexibility and scalability of cloud infrastructure are real.

This means hybrid is the future. But right now, it’s a future filled with inefficiency, wasted budgets and unnecessary complexity.

The Reality: Two Worlds That Don’t Talk

Here’s a real example. I was on a call with a large financial institution, and the goal was to show how to manage both on-prem resources with Ansible and cloud infrastructure with Terraform. But the on-prem person didn’t show up for some reason. It was a wasted meeting because the cloud team hadn’t a clue what the on-prem team did, so talk of cohesion between the two siloed departments was impossible.

A week earlier, I had spoken to their CTO, who was practically begging for a solution to bring these teams together. His teams were using completely separate toolchains, paying over $1 million annually for tools that didn’t even integrate. He had no visibility, no way to make informed decisions, and worst of all, no real collaboration between his teams.

This is very bad for business. It prevents the company from scaling, optimizing costs, and, most importantly, moving fast without breaking things.

Hybrid Is the Future, Whether We Like It or Not

In my opinion, hybrid is here to stay. Some workloads will always belong on-prem due to security, compliance or cost reasons. Others will thrive in the cloud, where elasticity and managed services make life easier. The problem is most organizations haven’t figured out how to make this coexistence work smoothly.

Right now, hybrid infrastructure feels like owning two cars but having no idea which one to use on any given day. Imagine having to change the tires, handle maintenance, and refuel separately for each—without even knowing how often you’re driving them. That’s what most CIOs are dealing with when it comes to managing a mix of cloud and on-prem workloads. Without unified visibility, decisions get made in silos, costs spiral out of control and teams get stuck in an endless cycle of firefighting instead of innovating.

Infrastructure as Code Orchestration: The Bridge We Need

This is where infrastructure-as-code (IaC) orchestration comes in. If hybrid infrastructure is inherently complex, then the answer isn’t just automation—it’s orchestration.

Automation alone won’t fix the fragmentation. You can automate tasks all day long, but if each team automates in its own way with different tools, you’re just adding complexity at scale. Orchestration, on the other hand, introduces a single layer of control—one set of workflows that unifies deployment and ongoing operational management across on-prem and cloud infrastructure.

Here’s what this actually means in practice:

● Visibility – Instead of scattered tools and isolated teams, you get a single source of truth for your infrastructure.

● Efficiency – No more redundant work. Instead of two teams doing similar things in totally different ways, orchestration allows for shared workflows.

● Security & Compliance – Unified policy enforcement across all environments. No more guesswork or inconsistent controls.

● Developer Velocity Without Losing Control – The ability to move fast while ensuring infrastructure changes are auditable, reversible and compliant.

I’ve seen companies try to duct-tape their way around this problem. They build custom pipelines with Jenkins or GitHub Actions, but eventually, they hit a wall. One company (who I can’t name, but let’s just say they handle a lot of digital documents) tried to do this with GitHub Actions, relying on one engineer to make it work. His salary alone cost them more than an orchestration platform, and if he left, they’d be completely stuck. That’s not a strategy—it’s a liability.

The CIO’s Next Move

If you’re a CIO dealing with hybrid headaches, here’s what you should be asking yourself:

1. Do I actually have visibility into both my on-prem and cloud environments? (If the answer is no, that’s problem #1.)

2. Are my teams working together, or are they operating as separate entities?

3. How much are we spending on redundant tools that don’t integrate?

4. What’s slowing down our infrastructure deployments, and is it avoidable?

The companies that solve this problem first are the ones that will be best positioned for the future. They’ll move faster, spend smarter and avoid the kind of growing pains that turn into existential crises.

If any of those questions made you uncomfortable, it’s time to rethink your approach. Hybrid doesn’t have to be a battleground. With the right orchestration, it can actually be an advantage

May 29, 2025

	Mainframe	Web	Cloud	Mobile	Agentic
Users	thousands	millions	100 million	billions	trillions
TPS	100	500	2,500	10,000	1,000,000
		5x	5x	4x	100x

Category: Techstrong Council

The Path Forward: Developer-First Security

Expanding to AI

Bridging Speed and Safety: Core Requirements for Secure Authorization

Shift One: Reasoning Is Moving Up the Stack

Shift Two: Deterministic Execution Becomes Essential

Shift Three: Human-Machine Collaboration is Entering a New Phase

A Clear Trajectory Emerges

How We Got Here

The Two Extremes

Filling the Gap: Intent-Driven Infrastructure

Guardrails Over Gates

The Lifecycle of an Idea

The Pressure Making this Idea Necessary, Now

Reality Check

Toward a More Human Infrastructure

1. Chasing Quick Wins

2. Automating in Silos

3. Starting with Rigid Foundations

Avoiding Past Automation Mistakes in the AI Era

The Code Boom and Its Paradox

Maker and Checker: A Model That Must Evolve

The Developer’s New Role

The Evolution of Security Roles

The SDLC Becomes a Continuous Risk Loop

Product Security 2.0: From Policies to Platforms

Compliance That Improves Security

Metrics That Matter in the AI Era

A Call to Action

The Ceremony of Audit

Security Processes vs. Human Behavior

Automation as a Lifeline

Infra Archeology: When You Don’t Know What’s Running

Context Is Everything in Logging

The Dangers of What You Don’t See

Policy as Code and Its Limits: Keep it Simple

Where AI Fits

Small Wins for Teams

The Human Factor

Why You Need to Start Now

Roles and Responsibilities Under the CRA

Specific Obligations for Organizations Building Software

Impact on DevOps Teams

Turning to the Community for Guidance

The Time to Act is Now

Bringing Order to Automation Complexity

AI: The Operationalizing and Scaling Challenge

How AI Can Be Integrated

Why Orchestration Helps Ensure AI and Automation Initiatives Play the Right Tune

Automation Is Inevitable, But Chaos Isn’t

The Scale Problem (a.k.a. We Broke TPS)

But What About Cost?

Latency, Reliability and Other Sad Stories

Capacity Planning Is Now Chaos Planning

The Blueprint (Such as It Is)

What Ops Teams Need to Do (Besides Cry)

Final Thought: The AI Agency Gap

Hybrid Isn’t Going Away—So We’d Better Get It Right

The Reality: Two Worlds That Don’t Talk

Hybrid Is the Future, Whether We Like It or Not

Infrastructure as Code Orchestration: The Bridge We Need

The CIO’s Next Move