Details
Cloud-native technologies have matured, but managing them across multiple clusters, clouds, services, and development teams remains difficult. In this DZone Trend Talk, moderator Jesse Davis speaks with Arjun Iyer, Raghava Dittakavi, and Shamsher Khan about the operational challenges uncovered in DZone’s 2026 Cloud-Native Foundations research.
The panel identifies environment drift, fragmented visibility, cross-cluster networking, delayed testing, and short-lived development environments as major sources of complexity. They also examine how AI-generated code is increasing pull-request volume and moving the delivery bottleneck from code creation to validation. Their central conclusion is that cloud-native scale depends on repeatable platforms, realistic early testing, controlled automation, and continued human accountability for production decisions.
Developers experience multi-cluster complexity when code succeeds in one environment but fails elsewhere because of configuration drift or different runtime conditions.
Platform teams experience the same problem through inconsistent configurations, limited visibility, networking boundaries, service meshes, API gateways, firewalls, and other infrastructure layers. Treating multi-cluster management as only a platform or development concern leaves important gaps unresolved.
A mature cloud-native platform is not simply one with documented standards. Teams need repeatable processes for building, testing, releasing, and operating software.
If the same unchanged release cannot move through the system consistently without manual adjustments, the platform has not yet achieved operational standardization.
A request to connect to one new third-party endpoint may appear minor. In practice, it can require changes to network security groups, firewalls, pipelines, shared infrastructure modules, and approvals from several teams.
These dependencies should be identified during discovery and design rather than after development is complete.
A local service change may affect upstream services, downstream state, databases, queues, cloud resources, and external APIs.
Unit tests can verify the modified component, but they cannot establish that the larger distributed system still functions correctly. Integration and system-level testing are essential when components evolve independently.
Defects become more expensive to diagnose when they are discovered hours or days after a pull request is merged.
By then, the developer may have switched tasks, and many other changes may have entered the shared environment. Early integration and feature-level testing reduce the delay between creating a change and learning whether it works.
A passed or failed test does not communicate the full risk of a release.
Teams can improve release decisions by considering the affected component’s history, prior regressions, customer impact, test results, service contracts, performance findings, rollback readiness, and the scope of the change. Some organizations are beginning to use AI agents to combine these signals into a risk score.
Per-branch or per-feature environments can provide realistic testing without forcing every change into a shared staging system. However, duplicating complete environments can be expensive.
Teams can manage this tradeoff through on-demand namespaces, temporary clusters, automated scaling, scheduled teardown, and shared or multiplexed infrastructure that preserves production-like fidelity without duplicating the entire stack.
As AI agents produce more code and more pull requests, writing the code becomes less constrained. The new bottleneck is establishing enough confidence to release it.
Functional validation, integration testing, performance analysis, security checks, runtime verification, code review, and approval all need to scale with the increased volume.
AI can assist with code review and static analysis, but inspecting code alone cannot reveal every problem in a distributed system.
The panel recommends running changed code in a realistic environment and testing its actual interactions with services, dependencies, networks, and data.
AI agents may take on more implementation, testing, remediation, and review work, but humans remain responsible for business intent, system design, governance, release thresholds, and production accountability.
The panel expects human involvement to move toward higher-level decisions rather than disappear.
Environment drift undermines release confidence
Practical implication: Standardize configuration templates and continuously compare clusters and environments for meaningful differences.
Visibility must cross platform boundaries
Practical implication: Correlate application, network, service-mesh, API-management, and infrastructure signals so teams can follow a request across clusters.
Discovery should include operational dependencies
Practical implication: Identify external endpoints, firewall changes, service contracts, data flows, and cross-team approvals before implementation begins.
Integration testing should happen close to the change
Practical implication: Give developers a way to test pull requests against realistic dependencies before merging into shared environments.
Testing depth should reflect change risk
Practical implication: Apply broader testing to high-impact business paths and historically unstable components while using lighter validation for low-risk changes.
Temporary environments need automatic expiration
Practical implication: Add scheduled shutdowns, idle-time detection, ownership labels, and budget controls to prevent abandoned environments from increasing cloud costs.
AI-generated code requires AI-assisted validation
Practical implication: Use agents to summarize changes, execute validation, identify probable failures, and recommend remediation while retaining human approval for consequential releases.
Production approval requires business context
Practical implication: Keep humans accountable for determining whether a change meets business intent, satisfies confidence thresholds, and has an acceptable rollback strategy.
Q: What makes multi-cluster Kubernetes difficult to operate?
A: Complexity comes from configuration drift, cross-cluster networking, inconsistent visibility, and the number of boundaries a request may cross. Those boundaries can include API management, service meshes, network security groups, firewalls, and services owned by different teams.
Q: Does multi-cluster complexity affect developers or platform teams more?
A: It affects both. Developers need consistent environments and fast feedback, while platform teams must maintain networking, visibility, governance, and standardized configurations across those environments.
Q: Why are unit tests insufficient for distributed applications?
A: Unit tests validate an individual service in isolation. They may not reveal how a change affects upstream consumers, downstream data, databases, message queues, cloud services, or third-party APIs.
Q: What does it mean to integrate and test early?
A: It means validating a change against relevant dependencies before it reaches a shared staging environment or the final delivery phase. This shortens feedback loops and makes failures easier to attribute to a specific change.
Q: Why do shared staging environments create slow feedback?
A: Many pull requests may be merged into the environment before a failure appears. The original developer may already be working on something else, and it becomes difficult to determine which change caused the problem.
Q: What is feature-based testing?
A: Feature-based testing applies validation according to the feature or business path affected by a change. A high-impact change may receive deeper integration and regression testing at the pull-request level than a low-risk modification.
Q: How can teams control the cost of temporary test environments?
A: Teams can create environments on demand, scale them down when unused, schedule automatic teardown, and share unchanged infrastructure across multiple sandboxes instead of duplicating the entire application stack.
Q: Where does AI move the software delivery bottleneck?
A: The panel expects the bottleneck to move toward verification and validation. More generated code creates more pull requests requiring review, integration testing, security checks, runtime validation, and release decisions.
Q: Can AI agents validate other agents’ code?
A: They can assist with code review, test execution, risk analysis, environment validation, and remediation recommendations. The panel recommends combining those capabilities with realistic runtime testing and human oversight.
Q: Where should humans remain involved?
A: Humans should remain responsible for business intent, system architecture, governance boundaries, critical release decisions, validation requirements, rollback strategy, and accountability for what reaches production.
Jesse Davis: Welcome to DZone Trend Talks. I’m Jesse Davis, and today we’re discussing findings from our 2026 Cloud-Native Foundations research and what they tell us about operating and delivering software across increasingly distributed, cloud-native environments.
The survey found that cloud-native architecture, developer workflows, reliability, cost, and automation are tightly connected. Multi-cloud and hybrid Kubernetes environments are common, but management practices remain uneven. Tool sprawl, environment drift, and slow feedback continue to complicate software delivery.
Our discussion will focus on the practical engineering choices behind these findings: how teams manage distributed environments, create reliable paths to production, test changes realistically, control costs, and prepare for a development model in which AI agents generate and validate more code.
With that in mind, I want to introduce the experts joining us today.
First is Arjun Iyer, co-founder and CEO of Signadot. We also have Raghava Dittakavi, Manager of Release Engineering and DevOps at TraceLink, and Shamsher Khan, Senior Specialist Engineer at GlobalLogic, a Hitachi Group company.
Welcome. We’re excited to have all of you here.
I want to begin with multi-cluster operations. Running multiple clusters is normal in cloud-native environments, but making them operate as one coherent system is difficult.
Once you move beyond a single cluster, where does the complexity appear first? Does it affect developers, platform teams, or both? Arjun, why don’t you start?
Arjun Iyer: From my perspective, I’m closest to the developer workflow. In multi-cluster environments, drift becomes a common challenge.
If each cluster is not an exact replica of the others, problems can appear in one cluster that did not surface in the environment tested earlier. Developers then encounter situations where something passed in one cluster but failed in production or another environment.
Environment drift is a common issue I hear about from developers.
Cross-cluster networking is another concern. Teams have to determine how networking should be configured between clusters so that, from the developer’s perspective, the system operates as one cohesive environment.
I’d love to hear what the others think.
Jesse Davis: Raghava, Shamsher, what do you think?
Raghava Dittakavi: I’m glad Arjun approached this from the developer’s perspective because I work on the delivery and platform side.
To answer your question, Jesse, I think the complexity affects both groups. It is not solely a platform-team or developer problem.
Drift is an important issue, as is consistency. Consistency does not necessarily mean making every cloud or cluster identical. Managing multiple clouds is not itself the most difficult part for a DevOps engineer.
The real challenge is consistency in configuration and visibility. When I’m debugging an issue, limited visibility adds time. A developer and platform engineer need to understand what the relevant specification and configuration look like.
Standardized configuration across multiple clouds, hybrid clusters, or even different environments within a single cluster helps teams scale and accelerate delivery.
Jesse Davis: Shamsher?
Shamsher Khan: Multi-cluster operations add another layer of complexity to the challenges that already exist in a single cluster.
When service A communicates with service B in another cluster, the request crosses several boundaries. A developer working in cluster A can see what is happening within that cluster but may not see what happens beyond it.
To make the environment consistent, teams need standardized processes across environments.
A service communicating with another cluster may pass through API management, a service mesh, network security groups, firewalls, and other network layers. Each boundary adds complexity.
That makes it more difficult to identify the root cause of an issue across multiple clusters or in a hybrid environment.
Jesse Davis: I’ve heard visibility and consistent processes from each of you.
What separates organizations that operate these environments as coherent platforms from those that struggle? Is there anything beyond visibility and process that viewers should consider?
Raghava Dittakavi: One factor is having a repeatable process for building and delivering software.
In a multi-cluster environment, the way you deliver and operate software should be repeatable from one release to the next. If nothing has changed, you should be able to repeat the process without making manual adjustments.
That demonstrates standardization, consistency, and governance. It requires a disciplined, well-orchestrated system.
Once the recipe is established, the ability to repeat it without altering the experiment shows that the organization is maturing.
Shamsher Khan: That maturity develops over time. Standardization does not solve every scenario immediately.
You may have standardized processes, shared pipelines, and common infrastructure libraries and modules. Then a new development requirement appears, such as allowing access to a third-party endpoint.
The endpoint sounds like a minor change, but enabling it can require work throughout the delivery chain. You may need to update a network security group, review firewall rules, coordinate with several teams, change infrastructure code, and update a shared pipeline.
The shared pipeline may have been designed to provide the same flow for every application. Enabling a separate branch or exception for one chain can become difficult.
These requirements need to be identified during discovery. Teams should begin determining how to implement the infrastructure, platform, and delivery changes from the first day instead of encountering them late in the process.
Jesse Davis: That moves us naturally toward development and QA.
A small change in a distributed application can affect a database, a message queue, an API, or infrastructure owned by another team.
How much of that system do you need to test when you make a change? Once an application is distributed across all these components, what makes integration testing so difficult, and what should teams do about it?
Arjun, let’s start with you.
Arjun Iyer: Enterprise applications are complex. It is no longer one service communicating with one database.
Multiple services coordinate and have runtime dependencies on one another. Add databases, message queues, third-party APIs, and cloud resources such as Amazon S3 buckets, and you have a complex distributed system that needs to be tested.
Each part of the system also changes at a different rate. Some services change frequently, others change less often, and database schemas may change independently.
From the perspective of a developer or coding agent, a change is usually local. It modifies one service or a small number of services, but the developer may not have the complete context needed to understand its broader effect.
A change may affect an upstream service that depends on it or alter state consumed by downstream services.
As the number of interacting components increases, integration and system testing become more challenging.
Unit tests may cover the individual service effectively. The difficult question is how to gain confidence that a local change has not disturbed or broken the larger system.
That is where I see the central challenge.
Jesse Davis: Raghava, you sit closer to production and delivery. Do you see the same problem, or does it look different from your position?
Raghava Dittakavi: I relate directly to what Arjun described about database schemas and API integrations.
There can be additional layers of complexity. A system may need to integrate with third-party government systems outside the United States. Data might be sent to or retrieved from another country, where the protocols are different.
One approach mature organizations use is to integrate early. Testing should not wait until the final delivery stage or until the change reaches someone in my role.
Integrate early, fail fast, learn, and move forward.
Agents are also beginning to help us evaluate the risk introduced by a code change. Rather than looking only at whether an individual test passed or failed, we can combine signals from integration tests, performance tests, and other sources.
From a delivery perspective, I need to decide whether a release should proceed. If the same component caused regressions or customer downtime in the past, that information should influence the decision.
The mindset should move beyond test status. We need to understand the risk being introduced.
When we integrate early but still plan to move a change into production, we need a risk assessment and rollback strategy. We are working toward generating that type of scorecard.
Jesse Davis: Are you using agents for that now?
Raghava Dittakavi: We are building agents to calculate risk.
The approach is not perfect because it depends on the available data, including test results and application contracts. In integration testing, the contract between applications or services is critical.
We are still working through how to use those signals to generate a meaningful risk score, but agents are part of that process.
Jesse Davis: That is a practical use of agents.
The old model in which development finishes its work and sends it to QA no longer works. Testing has to happen continuously as the change progresses.
Shamsher, is there anything you want to add?
Shamsher Khan: Agents can help validate environments and identify issues early.
Once a non-production environment is available, an agent can perform specific validation tests, identify issues, generate a report, and suggest remediation steps.
That helps the team identify potential causes before the change moves further through the delivery process.
Jesse Davis: That leads into the next issue.
As teams streamline delivery and offload more work to automated systems, the DZone research points to a broader workflow problem for developers.
Teams have CI/CD systems, deployment tools, observability platforms, policy engines, and testing frameworks. The friction often comes from switching between all those tools to determine whether a change will work and whether it is ready to merge and release.
Arjun, where do developers lose the most time between writing a change and knowing whether it can be merged and passed to the delivery team?
Arjun Iyer: Raghava’s point about testing early is important.
The further a defect travels through the software development lifecycle before being discovered, the slower and more expensive it becomes to fix.
That problem becomes more severe as agents produce more code. Developers are still accountable for the pull requests and units of code that will eventually be merged, even if an agent generated the implementation.
Testing early, or shifting testing left, becomes increasingly important.
Consider a pull request that is merged after only basic unit testing. The developer then switches to another task.
If that pull request later fails in staging, the failure might appear hours or days afterward. The developer has to return to the old work, reconstruct the context, troubleshoot the issue, roll back the change, and create a fix.
That creates a major developer-productivity problem.
The staging environment may also contain hundreds of additional pull requests by then. It becomes difficult to determine whether the original pull request caused the failure or whether one of the later changes was responsible.
Troubleshooting turns into a nightmare. Discovering issues late in shared environments creates long feedback cycles for developers.
Jesse Davis: I remember when developers had to lock files so only one person could edit them at a time. That was certainly slower, but today’s ability to merge many changes creates a different problem.
Raghava and Shamsher, what are you doing to reduce this friction?
Shamsher Khan: Earlier detection is better.
If teams use one shared environment to control costs, multiple teams may introduce changes into it. They should try to identify issues before changes accumulate in the shared environment or repository.
Catching an issue early makes it easier to resolve before many other changes are piled on top of it.
Raghava Dittakavi: This is the daily reality for most companies. No software organization is perfectly insulated from it.
The challenge is not only that a shared environment may be 100 pull requests ahead. The test branch may also be 100 changes ahead of the specific fix you are trying to validate.
One approach is to create stages of testing and apply stronger quality gates according to the code affected.
If a pull request touches a critical business path, it can receive more extensive testing than a change to a low-impact feature.
A feature-based sandbox can support more comprehensive testing at the pull-request level. Instead of relying only on unit tests or waiting for the integration phase, teams can test the affected feature earlier.
That introduces cost. Not every company is ready to maintain many separate sandboxes. But feature-based testing, where practical, can reduce delays later in the process.
Jesse Davis: It is a difficult problem. Teams have tried static code analysis at check-in and many other approaches. Everyone wants faster CI and shorter developer feedback loops.
Feature-based testing using infrastructure as code sounds promising: build the environment, deploy the feature, test it in a sandbox, and tear it down afterward.
But it comes with cost. The organization has to decide whether to invest in infrastructure or accept slower delivery.
Shamsher Khan: Teams are experimenting with feature-specific environments, but cost remains a concern.
One approach is to give developers a tool that creates an environment from their feature branch in a dedicated Kubernetes namespace.
The developer can scale the environment up when it is needed and scale it down afterward. Teams can also schedule automatic teardown during weekends or other inactive periods.
There are tradeoffs between cost and quality, but lifecycle controls can help.
Jesse Davis: How many of us have had a developer forget to tear down an environment and increase the cloud bill? I should raise both hands.
Arjun, does that approach align with what you have seen?
Arjun Iyer: Yes. That is close to what we address at Signadot.
Independent of any specific product, there are ways to reduce the cost.
One approach is to create a namespace or temporary cluster for a pull request and run validations there.
Another approach is to avoid duplicating the entire stack. Sandbox environments can multiplex a large number of full-stack environments without fully reproducing every component for each one.
Teams can implement similar patterns with service meshes, Kubernetes, and related systems.
This approach can provide the fidelity of a full-stack environment without paying the cost of complete duplication.
Jesse Davis: That brings us to AI.
We’ve discussed cost and efficiency, but AI can make the challenge either better or worse.
Developers can generate a staggering amount of code. As Raghava and Shamsher noted, the number of pull requests is growing, and the test changes can accumulate alongside the application code.
As AI creates work that would previously have required many more people, where will the delivery bottleneck move?
Arjun Iyer: Pull-request volume is increasing rapidly.
The bottleneck moves toward validating the code. Once the code is written, everything between that point and production is about establishing confidence to release it.
That includes functional verification, performance testing, security validation, and other checks.
The burden is shifting toward validation and verification. Because changes arrive from many developers and agents in parallel, organizations may have many pull requests waiting to be validated simultaneously.
That is where I see the bottleneck moving most rapidly.
Jesse Davis: Who performs that validation? Do other agents validate the code, or do humans continue to do it?
Arjun Iyer: It will be a combination.
Purely human code review becomes unsustainable when the volume is too high. Agents will have to validate some code, and tools already exist that review pull requests.
There are two sides to validation.
The first is static code validation. Agents can inspect the code and identify potential issues, but there is a limit to what can be learned by reading code alone.
The second is runtime validation. Teams need to run the code in an environment and execute tests against it.
That returns us to the environment discussion. Static analysis, AI-assisted review, and human review should be combined with tests of the running code in a realistic environment.
That is particularly important for distributed systems with many interacting components.
Shamsher Khan: I also expect a hybrid approach.
Humans are currently part of the approval process. When reviewers face a large number of pull requests, they already use AI systems to help review the changes and generate reports.
The reviewer remains responsible for approving the change, but the agent supplies analysis that helps make the decision.
As agents become more capable and controlled, their share of the validation process may increase. Human effort may decrease, but that transition will take time.
Jesse Davis: Raghava, is there anything you want to add before we move to the final question?
Raghava Dittakavi: I agree with Arjun and Shamsher.
Using Codex, Claude, Cursor, or another coding tool is becoming straightforward. I can speak a request and generate code.
The real challenge is validation and determining who owns that code.
Even if my agent created the implementation, I still need to accept responsibility for it.
The entire software development lifecycle is becoming AI-assisted, from the product-requirements document through production. Agents are participating throughout that process, but the familiar bottlenecks remain: software quality, validation, delivery, and rollback planning.
Humans understand the business logic and the intention behind a feature. An agent may miss that intent or overlook edge cases.
AI acceleration is real, but quality and delivery become the limiting factors.
Jesse Davis: That is where I want to end.
As delivery becomes faster and more complex, teams are relying increasingly on AI. A year or two from now, where should humans remain involved?
Shamsher, we’ll begin with you, followed by Raghava, and then Arjun will wrap us up.
Shamsher Khan: Human approval remains important when a change is going into production.
If I do not have full confidence in an agent’s recommendation, I will not give it complete authority to take the action. I will review and approve the change before it moves into production.
Human involvement may decrease as AI systems become more capable, but that requires giving agents better context and more secure ways to perform their work.
Broader access should not mean unrestricted action. Access needs to be isolated and controlled.
Making agents more capable also means making them more secure and adding appropriate gates. That is how organizations gain enough confidence to give agents more authority over time.
We have already seen significant progress, and we will see many more changes over the next several years.
Jesse Davis: Raghava, what do you think?
Raghava Dittakavi: AI is moving people away from purely execution-focused roles and toward system-level thinking.
Our expertise combines business knowledge with an understanding of the system. Humans should establish the intent, design the system, and define the boundaries. AI can then operate as an executor within those boundaries.
Today, people often design and execute. AI is increasingly capable at the execution layer, while humans move toward orchestration.
I agree with Shamsher about governance. We need controlled, isolated environments in which humans supervise what is happening, define clear limits, and teach the system what is acceptable.
Humans will focus more on business expertise, system design, and orchestration.
Jesse Davis: Arjun?
Arjun Iyer: Human involvement will move toward a more strategic level.
People will focus on critical decisions and on determining what should be built, rather than only on implementation.
Humans will remain in the loop, although the amount of direct involvement may decrease as agents improve.
Strategic judgment will still be necessary. Does a change meet the confidence threshold required for production? Are important validations missing from the test suite? What specific checks should a pull request pass before it ships?
The final decision should remain with a human because someone must be accountable for what reaches production.
I may have 10 agents shipping changes for me, but I remain accountable for those changes. That is where the human remains essential.
As agents become more capable, people will move toward higher levels of strategic thinking.
Jesse Davis: You are working at the intersection of two of the most interesting developments in software engineering: increasingly complex cloud-native systems and the growing use of AI throughout software development.
Thank you for sharing your expertise.
For everyone watching, I hope you enjoyed the discussion as much as we did. We could have continued for three hours.
If you want to find more conversations like this, visit DZone.com to explore our videos, research, and other resources created for the software-development community.
Thank you again. Have a great afternoon, evening, or morning, wherever you are.
Panelists: Thank you.
Presenters:
Arjun Iyer
Co-Founder and CEO, Signadot
Raghava Dittakavi
Manager of Release Engineering and DevOps at TraceLink
Shamsher Khan
Senior Specialist Engineer at GlobalLogic, a Hitachi Group company
Jesse Davis
Chief Technologist, DZone
Join Now for More Content & Events
For event and sponsorship inquiries, please email: [email protected]
