Why cloud modernisation leaves enterprises responsible for application resilience

Cloud modernisation leaves resilience with the enterprise

An enterprise can modernise its infrastructure, automate operations and adopt cloud-native services, designed to run in cloud environments, while its applications remain vulnerable to failure. Gartner identifies five shifts behind this tension: investment in speed and scale can coexist with growing fragility. It questions the “always-on” availability promise by asking whether organisations can still understand and manage failures across the services their applications depend on.

Gartner makes this argument in its invitation to the Gartner IT Infrastructure, Operations & Cloud Strategies Conference 2026. It has a commercial interest because it sells access to the event and benefits when leaders seek its guidance on resilience. Gartner promotes the conference as a place to understand emerging failure patterns, learn from current insights, compare resilience strategies and prepare for further disruption. It argues that growing distribution and interdependence will make these decisions more important.

For technology leaders, the practical question behind that invitation is whether abstraction has been mistaken for a transfer of responsibility. Abstraction lets teams use a service without managing all its underlying machinery, but the organisation remains accountable for how its applications behave when that service fails. As platforms take on more work, leaders therefore need to understand which responsibilities their teams must retain.

Application failure can begin above stable infrastructure

Retaining responsibility starts with distinguishing application availability from infrastructure health. Hardware and data centres can remain stable while an application becomes unavailable because a service it needs has failed. This is a service-chain failure: a failure among connected services prevents the application from working. Healthy infrastructure alone therefore cannot establish that an application has everything it needs to operate.

Gartner argues that modern outages rarely begin in physical infrastructure and instead arise among connected services. It identifies several possible failure points: identity systems, networking fabrics that connect infrastructure components, managed databases and third-party APIs, the interfaces through which applications use external services. In ‘From Automation to Reasoning: How AI Redefines Infrastructure’, Gartner ties this concern to the complexity of service chains and the automation operating above infrastructure. Assessing components separately leaves a question unanswered: how will the application behave when one becomes unavailable?

Connecting services across environments extends that question. In ‘Accelerating Operational Innovation From Cloud to AI’, Gartner highlights how hybrid architectures, which connect on-premises and cloud environments, and multicloud architectures, which use multiple clouds, introduce integration points that can become failure points. Each connection adds a relationship the organisation must understand. Application resilience therefore depends on how the full set of services works together.

Yet the team accountable for an application may see only some of those relationships. Cloud abstraction hides underlying complexity, while organisational boundaries can separate application ownership from knowledge of supporting services. A team can therefore be responsible for application availability while the cause of a failure sits outside the environment it can see. Incomplete visibility leaves that accountability unchanged.

Operational data must make dependencies understandable

Incomplete visibility can persist even when systems produce large amounts of data. In ‘The Distraction Tax: How Operational Noise Is Quietly Killing Innovation’, Gartner describes how alert volume and duplicated telemetry, the data systems produce about their condition and behaviour, overwhelm operations teams. More data can make important changes harder to recognise when useful signals compete with repeated or routine notifications.

Gartner links this operational noise to reduced attention, which makes early signs of wider failure harder to distinguish. Hidden dependencies compound the problem because a team may see a warning without understanding which application it threatens. Excessive warnings, in turn, make that relationship harder to investigate. A weak link can remain unidentified even when data about it exists somewhere in the environment.

Understanding those relationships requires visibility beyond the enterprise’s own systems. In ‘Leadership Vision 2026: Infrastructure and Operations Through 2028’, Gartner analysts emphasise governance and visibility across operational domains, including “third- and fourth-party services”. Fourth-party services supply an organisation’s own providers, so exposure can extend beyond direct supplier relationships. Governance must reach far enough along these dependencies for leaders to understand the risks their applications inherit.

Automation requires retained human expertise

A clearer view of dependencies still leaves a practical question: can people act when a failure exceeds what automation can handle? Gartner contrasts current cloud operations with the data centre era, when the continuing threat of hardware failure prompted regular disaster-recovery practice. Repeated exercises built operational discipline and practical knowledge of how to restore systems. Teams could draw on that experience when something went wrong.

Cloud abstraction changes how often teams practise recovery because platforms handle more of the underlying operations. Gartner argues that reduced contact with failure and recovery processes can weaken practical experience. An organisation may therefore assume its people retain a response capability they have fewer opportunities to exercise. The risk grows when operating arrangements change without a matching decision about which skills to maintain.

AI-driven automation makes that decision more important. In ‘Autonomous IT: A New Paradigm for Secure Endpoint Management with AI in Real Time’, Gartner describes systems that observe conditions, reason about them and act without human intervention. As these systems take over work that previously required direct attention, leaders must consider who can understand and manage an unexpected failure. Delegating execution changes how work happens while leaving the enterprise responsible for the consequences.

Gartner addresses this capability in ‘I&O Skills: What’s Needed Now, What’s Needed in the Future’, which stresses rebuilding infrastructure and operations skills rather than assuming cloud platforms will absorb all complexity. These skills include the practical ability to respond when systems behave unexpectedly. Automation can improve efficiency while reducing opportunities to gain that experience, so leaders need to decide deliberately how to retain expertise. Continued investment in skills helps teams use autonomous systems while preserving the judgment to recognise their limits.

Architecture and governance must prepare for failure

Retained expertise needs an architecture that gives people useful options when failure occurs. Distributed systems, applications whose work spans connected services, will encounter failures, so architectural choices must account for them. Gartner calls for examining weaknesses in how services fit together and investing in frameworks that guide consistent resilience decisions. Preparation means confronting difficult architectural findings and allowing them to change the design.

Dependency visibility gives these decisions a basis, while governance makes the resulting risks part of operational responsibility. In ‘Accelerating Operational Innovation From Cloud to AI’, Gartner connects this work with proactive governance and predictive operations, meaning operations that anticipate emerging problems. Prediction helps when people and automated systems understand which dependencies a warning affects and can act before the problem spreads. Its value depends on connecting information to a decision about application behaviour.

Leaders can test whether that connection exists by asking: “Do we know our full dependency chain?” The answer must include services across organisational boundaries, direct providers and those providers’ suppliers. It must also distinguish collected data from an understandable account of which services rely on which others. Finding relationships that remain unclear exposes gaps that can otherwise conceal weak links.

Once those relationships are understood, the architectural question becomes: “Can our systems degrade gracefully when a service fails?” Graceful degradation means continuing to provide useful service when a dependency becomes unavailable, even if some functionality is lost. Assessing it requires examining the application’s behaviour under failure, especially where integration creates more ways for a problem to spread. Component health cannot answer that application-level question.

Even an architecture designed to tolerate failure needs people prepared to intervene, which makes the final question practical: “When was the last time we conducted a manual resiliency drill?” The exercise tests what people in the organisation can do directly when automated operations are insufficient. Where automation has reduced hands-on experience, a drill tests whether the response capability leaders assume is still available. Its findings can reveal skills and preparation that need renewed investment.

Key executive takeaways

• Retain ownership of resilience: Cloud platforms take over operational work while the enterprise remains accountable for application availability. Technology leaders need explicit decisions about which responsibilities and recovery capabilities remain in-house.
• Map service dependencies: Application owners need visibility into identity systems, networking, databases and external APIs across cloud environments. Extend that view to providers’ suppliers to expose risks beyond direct contracts.
• Make operational data useful: Operations teams need alerts that connect service problems to the applications they threaten. Reducing duplicated telemetry and clarifying dependencies helps teams recognise early signs of wider failure.
• Preserve recovery expertise: Infrastructure and operations leaders need to maintain hands-on recovery skills as automation absorbs routine work. Manual resilience drills test whether people can intervene when automated responses are insufficient.
• Design for service failure: Architects need to assess whether applications retain useful functionality when supporting services fail. Use dependency maps and drill findings to prioritise design changes, governance gaps and skills investment.