devopsy.kinsta.cloud

Tag: cloud-native infrastructure

MCP-Powered Agentic AI in DevOps: Building Secure, Scalable Multi-Agent Pipelines for Autonomous SRE and Observability
The next evolution in DevOps isn’t just about automation, it’s about autonomous intelligence. As organizations scale their cloud-native infrastructure, traditional monitoring and incident response approaches are reaching their breaking point. Enter model context protocol (MCP) powered agentic AI: A paradigm shift that transforms how we build, deploy and maintain resilient systems through collaborative AI agents.

The Challenge: Complexity Outpacing Human Capacity

Modern DevOps teams manage thousands of microservices across multiple clouds, each generating terabytes of telemetry data daily. Traditional site reliability engineering (SRE) practices, while valuable, struggle with:
- Alert fatigue from thousands of non-actionable notifications
- Context switching between dozens of monitoring tools
- Manual investigation during critical incidents
- Knowledge silos when senior engineers are unavailable
The result? Mean time to resolution (MTTR) continues climbing even as organizations invest heavily in observability tools.

Enter MCP: The Foundation for Agentic DevOps

MCP emerged as the ‘USB-C for AI’, a standardized way for AI models to securely interact with external tools and data sources. Unlike traditional API integrations requiring custom code for each connection, MCP provides a universal protocol that any AI agent can use to:
- Access infrastructure APIs without exposing credentials
- Execute predefined operations within security boundaries
- Share context across multiple specialized agents
- Maintain audit trails for compliance requirements
This protocol enables what was previously impossible: Multiple AI agents working together as a coordinated team, each specializing in various aspects of the DevOps life cycle.

Building Multi-Agent SRE Teams

An MCP-powered agentic architecture creates specialized AI agents that collaborate like expert team members:

The Orchestrator Agent

It serves as the team lead, receiving high-level objectives such as ‘maintain 99.9% availability for payment services’. It breaks these goals into specific tasks, delegates to specialized agents and coordinates their activities while maintaining situational awareness across the entire system.

The Observability Agent

It specializes in telemetry analysis, connecting to your existing monitoring stack through MCP servers. Instead of drowning engineers in raw metrics, it provides contextual insights: ‘CPU utilization spike correlates with increased database connection pool usage, suggesting a connection leak in microservice X’.

The Remediation Agent

It focuses on safe, automated responses to common issues. Through MCP, it accesses your runbook library and executes predefined remediation actions, rolling back deployments, scaling resources or restarting services, while maintaining human oversight for critical changes.

The Security Agent

It monitors for anomalous behavior patterns that might indicate security incidents. Using MCP to access vulnerability databases and security scanning tools, it can automatically patch low-risk vulnerabilities or escalate high-risk findings to human security teams.

Real-World Implementation Patterns

Organizations implementing MCP-powered agentic systems report dramatic improvements:

Incident Response: A fintech company reduced MTTR from 45 minutes to under 5 minutes by deploying agents that automatically correlate alerts, identify root causes and execute remediation playbooks, all while keeping humans in the loop for approval on production changes.

Capacity Planning: E-commerce platforms use prediction agents that continuously analyze traffic patterns and automatically scale infrastructure hours before predicted demand spikes, reducing costs while maintaining performance.

Security Posture: SaaS companies deploy agents that continuously scan for vulnerabilities, automatically apply low-risk patches during maintenance windows and coordinate with security teams for complex remediation efforts.

Security and Governance Considerations

The autonomous nature of agentic AI requires robust security frameworks:

Principle of Least Privilege: Each agent receives only the MCP permissions necessary for its specific role. The remediation agent cannot access customer data; the observability agent cannot modify infrastructure.

Human-in-the-Loop Design: Critical operations require human approval. Agents present recommended actions with confidence scores and potential impact analysis before execution.

Audit and Compliance: MCP maintains detailed logs of all agent activities, creating audit trails that satisfy regulatory requirements while providing transparency into autonomous operations.

Circuit Breakers: Automatic fail-safes prevent agents from taking actions that could cascade into larger outages. If an agent’s remediation attempts fail repeatedly, the system automatically escalates to human engineers.

Getting Started: Practical Implementation

Organizations need not rebuild their entire DevOps stack to benefit from agentic AI. Start with these proven approaches:

Phase 1 – Observability Enhancement: Deploy a single observability agent to analyze existing monitoring data and provide contextual insights. This low-risk introduction demonstrates value while building organizational confidence.

Phase 2 – Automated Remediation: Add remediation capabilities for well-understood, low-risk issues such as certificate renewals, service restarts or configuration updates. Maintain human approval gates for all production changes.

Phase 3 – Multi-Agent Orchestration: Introduce specialized agents for security, performance and capacity planning of different domains, coordinated through an orchestrator agent that manages complex workflows.

Phase 4 – Predictive Operations: Deploy agents that learn from historical patterns to prevent issues before they occur, moving from reactive to proactive operations management.

The Future of Autonomous DevOps

As MCP adoption grows, we’re witnessing the emergence of truly autonomous operations — where human engineers focus on innovation while AI agents manage routine operations. Early adopters report 70% reductions in manual interventions and 50% improvements in system reliability.

The key to success lies not in replacing human expertise but in augmenting it, creating human-AI teams that combine the creativity and strategic thinking of experienced engineers with the tireless precision of autonomous agents. Organizations that embrace this paradigm shift today will gain significant competitive advantages in tomorrow’s digital landscape.

The future of DevOps isn’t just automated — it’s intelligent, collaborative and autonomous. MCP-powered agentic AI makes that future accessible today.
February 4, 2026
From Cloud to Cognitive Infrastructure: How AI is Redefining the Next Frontier of SRE

As organizations embrace artificial intelligence (AI) workloads alongside traditional cloud systems, site reliability engineering (SRE) must evolve to manage an entirely new class of infrastructure — intelligent, hybrid and graphics processing unit (GPU)-driven.

Infrastructure has transformed dramatically over the past two decades. We began with physical servers in local data centers, then virtualization improved efficiency by abstracting compute resources. The public cloud changed everything, offering elasticity and scalability that on-premises environments couldn’t match.

SRE emerged during this cloud era to bridge the gap between developers and operations. SREs took on responsibility for ensuring systems remained observable, automated and resilient at scale. The discipline matured alongside cloud adoption.

However, complete cloud dependence created new challenges. Costs escalated, compliance requirements grew more complex and organizations sought greater control. The hybrid and multi-cloud approach became the answer, enabling companies to balance workloads across on-premises infrastructure, public cloud and multiple providers.

For a while, this hybrid model seemed like the final evolution. Then AI arrived and transformed the conversation entirely.

AI Demands Different Infrastructure

AI isn’t just another application you can throw on existing infrastructure — it requires fundamentally different resources.

Traditional compute runs on central processing units (CPUs) and manages predictable workloads. AI models, however, demand massive parallel processing, specialized GPUs and tensor processing units (TPUs) and extremely low-latency connections between training and inference systems. This hardware is expensive, in short supply and concentrated in specific geographic regions.

Cloud providers have rolled out AI-optimized instances, but enterprises are quickly realizing that the math doesn’t work long-term — costs add up fast. Data sovereignty matters more than ever. Control is critical, especially for model training and fine-tuning.

So, we’re seeing something unexpected: The data center is making a comeback. However, this isn’t your old-school server room — these facilities are smarter, distributed and tightly interconnected with cloud resources.

Companies are now running two parallel infrastructure tracks: One that oversees traditional workloads such as microservices, applications and application programming interfaces (APIs) and another that manages AI workloads, including model training, inference, vector search and data pipelines. Managing both simultaneously introduces complexity we haven’t dealt with before.

The hyperscalers and tech giants have the resources and expertise to handle this dual-infrastructure challenge. But what about everyone else? Mid-sized enterprises and even mature organizations without those hyperscale resources are facing the same demands without the same depth of talent or budget. They’re being forced to figure out AI infrastructure alongside companies that built their businesses on distributed systems from day one.

SRE Gets More Complex

SRE has always adapted to infrastructure changes, and AI is driving yet another evolution. This time, however, the complexity is on a different level.

The reliability metrics that worked for traditional systems no longer fully capture what matters for AI infrastructure. Yes, we still care about latency, availability and error budgets — but now we also need to track GPU utilization efficiency, because idle GPUs can burn thousands of dollars per hour.

Inference reliability matters too — models must respond consistently even when loads fluctuate wildly.

Data freshness has become a reliability concern. If training data gets stale, model performance degrades — something a traditional uptime metric will never detect. Additionally, we can’t ignore energy and cooling efficiency anymore. GPU clusters consume enormous amounts of power and generate serious heat.

Observability must also evolve beyond what we’re used to. Traditional metrics and traces are no longer enough. We need real-time visibility into model-serving health, GPU cluster orchestration and pipeline performance. That means combining cloud-native observability tools with AI-specific telemetry systems.

The Hybrid AI Reality

Organizations didn’t abandon their data centers when cloud computing arrived, and AI infrastructure won’t replace cloud either. Instead, they will coexist, creating new architectural patterns.

We’re already seeing hybrid AI clusters, where companies train models on- premises for data control and then scale inference workloads out to the public cloud. AI-aware load balancers can now route intelligently — sending inference requests to GPU-backed nodes while directing standard web traffic to CPU clusters. Cross-cloud orchestration layers are emerging to manage workloads seamlessly across data centers and hyperscalers.

SREs sit at the center of this evolving ecosystem. They ensure reliability across CPUs, GPUs and data pipelines. Both AI and traditional services must meet their service level agreements (SLAs), and SREs have to make that happen across an increasingly complex environment.

When AI Manages Reliability

Here’s where it gets interesting: AI won’t just be another workload to manage — it’s beginning to assist with reliability management itself.

AI-driven SRE platforms are emerging that can predict outages before they happen, recommend scaling actions based on patterns humans might overlook and auto-heal systems without manual intervention. The technology is rapidly improving at identifying problems and resolving them automatically.

However, even with increasing automation, the human element remains essential. SREs provide context, understand trade-offs and assess risks in ways that automated systems can’t replicate. The SRE of the future won’t just manage services — they will also manage the intelligence that manages those services. That’s a significant shift in responsibility.

What Comes Next

Infrastructure evolves to solve new challenges. Virtualization brought efficiency. Cloud brought scale. Hybrid brought flexibility. Now AI brings intelligence — along with substantial complexity.

As enterprises build these hybrid AI infrastructures, the demand for resilient, efficient and adaptive operations will only intensify. Tomorrow’s site reliability engineers will need expertise in both traditional infrastructure and AI systems. They will ensure not just uptime, but also model performance, GPU efficiency and intelligent reliability across both worlds.

AI infrastructure isn’t replacing cloud computing — it’s extending it in new directions. SREs will be the ones ensuring everything works together — seamlessly, securely and intelligently. The role is evolving once again, and that transformation is already underway.

October 24, 2025
4 Container Orchestration Security Concerns
Container orchestration is a must-have technical skill, according to 51% of respondents to the 2021 Upskilling survey from DevOps Institute. So, it’s no surprise, then, that container technology is becoming increasingly popular. However, container environments are far more complex and dynamic than other infrastructure, making container security essential. Security ensures containers are running as intended, protecting the infrastructure, software supply chain, runtime and everything in between.

If you’re looking to use container-based applications within your software infrastructure, you may want to keep in mind the security risks that come with this technology. To help, I asked DevOps Institute Ambassadors to weigh in on the security concerns they have with container orchestration. Here’s what they shared:

Anshul Lalit, head of technology and transformation, Kongsberg Digital

“One of the most common security concerns with container orchestration is that it shares the host operating system and the host kernel. Thus, it raises the concern that a host OS or kernel vulnerability could potentially be taken advantage of and exploited in a container. An example of this is the recent attacks on Linux’s mmap syscall. Though you can avoid this by using defined best practices, it’s worth noting that any compromise in the host OS could compromise containers in that host. This scenario is in contrast to a virtual machine (VM), in which the guest OS and the host OS and kernel share no common binaries and are thus inherently separated.

Similarly, a rogue process, a vulnerable container image that is running, and a security vulnerability in the orchestrator can all provide an attacker a means to get their foot in the door. For example, if a container is designed to run with root privileges, an attacker running a vulnerability scanner on the orchestration host will quickly find the vulnerable container.

Users should follow best practices for securing the containers running in a container orchestration platform by providing a Linux security module, for example, that can enforce a policy that will protect against a rogue container or user from extracting sensitive data from the host system.”

Supratip Banerjee, solutions architect, Principal Global Services

“Containers are creating new challenges for cloud security. While these structures are dynamic and automated, new threat vectors are also present for precisely the same reasons containers are useful. DevOps and SecOps teams must be aware and prepared for these possible issues:
- Containers, unlike virtual machines, share the host operating system on which they execute. If settings are not correctly maintained, the host and containers may be exposed to security concerns.
- Orchestration automation adds a degree of complexity which can lead to misconfigurations that overprovision access and, as a result, an expanded attack surface.
- Containers are constructed using pictures kept in public or private repositories; they are frequently reliant on other images, and a single flaw in any of them might spread across thousands of containers.
- Because containers are ephemeral, IP address-based security measures are ineffective and complicate forensic investigations.”
Parveen Arora, co-founder and director, VVnT SeQuor

“If your project(s) involves the use of containers, you will have decomposed your application into its various constituent services, which, while beneficial, isn’t necessarily as secure as if you are using VMs. Since container platforms like Docker borrow code libraries from the host, they’re fundamentally not as secure as VMs. Vulnerabilities in a container environment can therefore allow malicious software to break out of a container and infect the host environment.”

Vishnu Vasudevan, head of product engineering and development, Opsera

“The security challenge, especially when it comes to container orchestration, is people think they can spin up their own image or they can download the image from the cloud and start using it. It’s not as easy as everybody thinks. There are vulnerabilities being introduced every minute. You need to have a security tool and processes that can automatically scan for every container that is being splintered. Furthermore, a team needs to create shared practices around blue-green deployments or rollbacks of the container changes that are being pushed into production.

From the pandemic alone, we have seen significant cloud movement, but on average, 50 vulnerabilities are introduced every day. In fact, there are people just waiting for loopholes where they can execute malicious scripts. And some people, especially people who are in mining, try to gain visibility into vulnerabilities within cloud accounts and penetrate them to run huge containers for their own cloud mining purposes. On average, it can take 280 days to even detect any vulnerabilities or a hack into the system.

Companies using containers must consider threat vulnerability management as part of their orchestration strategy. Do you think the team is experienced enough to scan 50 vulnerabilities a day and fix them? Probably not, since release velocity is shortening a release cycle to one or two weeks for modern application initiatives. This creates a lot of technical debt that can accumulate rapidly, which is why threat vulnerability tactics and processes must be considered when moving to the cloud.”

Learn more about container orchestration and similar topics by registering for an upcoming SKILup Day.
October 7, 2021
7 Trends Influencing DevOps and DevSecOps Adoption

Enterprise technology adoption trends can be broadly categorized under three pillars: infrastructure, architecture and technology. Let’s explore what these trends are and how they influence DevOps and DevSecOps adoption in tech corporations worldwide.

Trends in Architecture

In computing, architecture is the collection of protocols encompassing the utility, structure and execution of software applications. Architecture defines how an application works and determines the function of each component, such as data storage and computing capability, for example. Architecture trends directly influence how technology is developed, which also makes it influential on the field of DevOps.

Trend #1: Monolithic to Microservice Architecture

The shift from massive, inflexible systems that limit compatibility to lightweight, nimble software has increased DevOps and DevSecOps adoption. As architectures such as containers become mainstream, it is easier than ever for teams to code, debug and deploy software quickly, and work collaboratively. Microservice architecture offers the benefit of quickly being able to install, run and maintain systems, and is a catalyst to greater DevOps adoption, while containers spur DevSecOps adoption.

Trend #2: Cloud-First Trend

Mobile-first, cloud-first development has revolutionized data transportation, security and collaboration, and made development efficient, safe and transparent. This approach leads many organizations to adopt DevOps/DevSecOps.

Trends in Infrastructure

In IT, infrastructure refers to software, hardware, networking resources, systems and tools that allow companies to operate and manage their production processes.

Infrastructure trends also heavily influence both the hardware and software tools companies use for tracking and manufacturing their products, and therefore directly impact their willingness to adopt DevOps and DevSecOps.

Trend #3: Kubernetes Plus/Minus DevOps

A significant infrastructure trend that affects DevOps is the increasing adoption of Kubernetes by global technology companies. Kubernetes is open-source software designed to orchestrate the management, deployment and scaling of containers, and has seen widespread adoption in the tech industry. Kubernetes empowers organizations to be more productive, with an emphasis on security and collaboration. Containers in Kubernetes seamlessly allow multiple teams to develop a project simultaneously. Resource management and transparency are significantly enhanced, bugs can be fixed more quickly and work cycles can be shortened.

Kubernetes and container management systems also reduce the need for human interaction and facilitate a fully automated, ‘NoOps’ scenario. Kubernetes uses a pipeline architecture approach that makes it easier for developers to use AI and ML tools to analyze, predict, and automate data and work processes.

Furthermore, Kubernetes sets an infrastructure backed on logging, continuous detection, consistency, and self-healing, making it extremely easy and considerably faster for computers to make sense of the data, potentially eliminating human interaction. The infrastructure established by the trendy Kubernetes technology is both advancing and restraining DevOps adoption in companies worldwide, depending on how the companies implement Kubernetes into their work cycle.

Trend #4: The Agile Infrastructure Trend

Agile infrastructure for software development has become the standard for software development, and is perhaps the most influential trend impacting DevOps adoption. Agile, like DevOps, focuses on collaboration, organization, diversifying skill sets to achieve resilience, rapid iteration and self-improving work processes. Adapting to an Agile methodology means each team has members skilled in various disciplines that work in concert. Each product delivered is followed by a feedback cycle. Agile teams in an enterprise are transparent, collaborative and resilient to internal and external conditions.

Trends in Technology

Advancements in technology enable new ways of thinking and new best practices. As tech trends change, the work cycles, processes and mindsets also evolve.

Trend #5: Release & Deployment Automation

Manually moving software between testing and production environments is an inefficient, painful task that must be repeated every time updates are added, new versions are released or new features are built. But with the rise of release and deployment automation, software companies can entirely automate this process, saving time while boosting reliability. With the click of a button, test code can be automatically converted to production-ready work and deployed to version controls or hosting services. With this use of automation, DevOps adoption skyrockets.

Trend #6: Site Reliability Engineers

Site Reliability Engineers (SREs) are in huge demand as organizations strive to create highly scalable and secure software. SREs build robust, reliable software that leverages automation, create self-healing systems that focus on operations and align closely with business imperatives.

Trend #7: Shift Toward AI/ML

The evolution of artificial intelligence and machine learning is changing our entire perspective on the development and use of technology. With increasing automation, ML systems can process large amounts of data, make reliable predictions and provide extremely accurate analyses. AI can make use of this data and these predictions to determine what to do next, and create truly intelligent machines that can function with minimal human interaction.

While this makes systems faster, more autonomous and reliable—which aligns with what DevOps promotes—it can eventually create a NoOps cycle that doesn’t require human intervention. In the short-term, this trend does influence DevOps adoption, but, in the long term, AI/ML could ultimately eliminate DevOps altogether.

January 7, 2021
Q&A: CNCF on Instilling a DevOps Culture, Part 2

In part one of this two-part series, devopsy.kinsta.cloud introduced the Cloud Native Computing Foundation (CNCF), a nonprofit organization with 49 members engaged in promoting the development of cloud native applications. Let’s continue with the CNCF’s thoughts on instilling a DevOps culture.

devopsy.kinsta.cloud: Why do developers need the freedom to choose how they build software? What kinds and levels of freedom? Is this about approaches, development tools or something else?

Brian Grant: All of the above: approaches, tools, languages … Different solutions work better for different workloads, scenarios, environments and people. Even new applications developed from scratch to be cloud-native aren’t typically developed in a vacuum—their developers may be familiar with particular languages or tools, the new application may need to interact with legacy applications; it may need to be built with and/or deployed onto existing infrastructure, etc. Often developers need to be able to adopt new technologies or approaches incrementally.

devopsy.kinsta.cloud: How do you recommend providing this freedom to developers? How do you help provide it?

Grant: Containers provide an ideal mechanism for providing this freedom, since they can be used to deploy both new and legacy applications, written in any language, built by any tool, into any environment. It’s a goal of the CNCF to foster an ecosystem of composable technologies, such as Kubernetes that facilitate the management of container-packaged applications.

devopsy.kinsta.cloud: How does this align with instilling a DevOps culture?

Grant: Because containers are small and fast, one application can be packed in each container image. Consequently, immutable container images can be created at build/release time rather than deployment time, since each application doesn’t need to be composed with the rest of the application stack nor integrated into the production infrastructure environment. This empowers developers to deliver deployable artifacts to operations.

devopsy.kinsta.cloud: How is code reuse a need of the developer?

Craig McLuckie: The vast majority of the actual code that is run in any given deployment is written by others. Only a tiny fraction of code in any given instance is actually written by the developer. The rest is everything from common libraries, to full OSS subsystems, to commercial software that systems, to adjacent software projects that provide some business functions. Developers need a common way to integrate with existing systems (when it makes sense) or to find and reuse existing code in a way that is controlled and operations-friendly.

devopsy.kinsta.cloud: How do you recommend giving developers the ability to reuse code? How does your organization help with this?

McLuckie: CNCF stands behind two technologies that are critical to code reuse. The first is the use of containers, which represent an intrinsically easy and predictable way to reuse even a relatively complex piece of software. The second is microservices-based architecture that make it easy to wire together systems and reuse existing services versus having to build their own.

devopsy.kinsta.cloud: How does this align with instilling a DevOps culture?

McLuckie: Containers make operations far more predictable and reduce possible avenues of error when deploying and updating systems. Rather than run potentially error prone imperative configuration systems to reuse code, containers are simple, lightweight and predictable, and reduce the potential for errors.

Microservices allow for better operations specialization and create systems that are more intrinsically agile and easy to evolve. They allow for smaller teams that are focused on delivering a specific function versus having to align around large system boundaries. This creates a more productive and operationally viable environment.

devopsy.kinsta.cloud: What is cloud-native? What does that mean?

McLuckie: For CNCF, ‘cloud native’ is about a new pattern of application development that was pioneered by the internet companies, but that is equally applicable to developers and operators running more traditional workloads.

We see three common attributes that make systems ‘cloud-native’:

Container-packaged: Applications and processes are run in software containers as a unit of application deployment, which facilitates reproducibility, transparency and resource isolation. This improves overall developer experience, fosters code and component reuse, and simplifies operations.

Dynamically managed: Applications are actively scheduled and managed. This radically improves machine efficiency and resource utilization while reducing the costs associated with maintenance and operations.

Microservices-oriented: Applications are loosely coupled, with dependencies explicitly specified. This significantly increases the overall agility and maintainability of applications.

Together, these three capabilities allow developers to build systems that are intrinsically agile and scale well. They significantly reduce the operational complexity of running an application, allowing operators to be more focused on application-level concerns and relying heavily on smart systems to do the operations heavy lifting.

June 21, 2016
Q&A: CNCF on Instilling a DevOps Culture, Part 1

The Cloud Native Computing Foundation (CNCF) is a non-profit comprised of some 49 industry participants that have come together to drive development and adoption of cloud-native applications and services. The CNCF is uniting such giants as Google, IBM, Intel and Cisco Systems to distill a collection of container technologies that end-user companies deem praiseworthy to reach its goal.

The CNCF intends its membership to represent end users (the CNCF website lists one end user, Goldman Sachs), cloud and container technologies, online and IT services, and academic institutions.

On behalf of the CNCF, Craig McLuckie, its Governing Board chair, and Brian Grant, its Technical Oversight Committee representative, weigh in on leading the DevOps transformation and instilling a DevOps culture in this two-part Q&A.

devopsy.kinsta.cloud: How is the CNCF specifically involved in leading the DevOps transformation by instilling the DevOps culture, in the industry or in member companies, for example?

McLuckie: We believe that at the heart of the DevOps culture is the need to reduce the friction and, indeed, the barriers between teams that build an application and the teams that run an application. Developers learn to think about an application as a living service that evolves continuously and rapidly to meet the evolving business needs. Operations is there to deliver the tools and environment needed for them to successfully drive their application.

devopsy.kinsta.cloud: Why do developers need an environment that is safe to change? What kind of change? Safe how?

McLuckie: Safe change has many potential meanings: The first kind of “safe” is about creating deterministic behavior in operations. Does the system handle a change correctly every time? If I make a change to two systems, will they have the same state? How about to 1,000 systems? It’s important to focus on creating strong determinism by removing the moving parts in a production deployment.

The second kind of “safe” is about being able to validate that a change is good—not just in pre-production environments, but in the actual production environment—with a simple and deterministic rollback. It is important to make it trivial to replicate environments, and offer a way to run a simple experiment in production (e.g. route 1 percent of my traffic to this new version) with the option to deterministically roll forward or backward without effort.

A third kind of “safe” is about being able to ensure that every change is deliberate. One of the problems we often see in production systems is “configuration drift” that isn’t driven through any kind of formal process. This should be addressed by creating a strongly declarative toolset that makes every change deliberate and trackable.

devopsy.kinsta.cloud: How do you recommend providing these things that developers need? How do you help provide them?

McLuckie: There are multiple issues like data, security governance and applications that need to be addressed. Additionally, companies want to deliver apps with high velocity. How do you solve all of this? A vendor-neutral organization that can harmonize emerging technologies is important for facilitating cloud-native. Given the large number of players in the marketplace with competing approaches, having an open source way to solve this is also important.

Grant: Cloud-native infrastructure enables self-service and “hands-off” operation, including provisioning, deployment, scaling, healing, discovery, monitoring and more, with relatively little marginal effort for specific applications. By supporting open source projects such as Kubernetes and Prometheus that provide such functionality, the CNCF hopes to democratize high-velocity application delivery, which was previously achievable mainly by web-scale companies.

devopsy.kinsta.cloud: How does this align with instilling a DevOps culture?

Grant: In a DevOps culture, operators are both partners and customers of the developers. Developers take responsibility for meeting operational requirements: security, reliability, availability, scalability, efficiency, actionable monitoring and logging output, necessary configurability, compatibility with the production environment, etc. Cloud-native infrastructure provides mechanisms developers and operators need to facilitate and capitalize on those capabilities.

Stay tuned for part two of the CNCF interview.

June 14, 2016