For much of the past two decades, the movement towards cloud computing has been presented as an almost inevitable stage in the evolution of enterprise technology. Organisations were encouraged to move away from capital-intensive data centres, reduce their ownership of physical infrastructure and embrace the flexibility of computing resources delivered as a service. The underlying proposition was persuasive because it addressed genuine limitations in traditional IT operating models. Maintaining privately owned infrastructure required substantial capital investment, specialist technical expertise, long procurement cycles and the difficult task of forecasting future demand. Public cloud platforms offered an alternative in which computing resources could be provisioned rapidly, scaled according to demand and integrated with an expanding ecosystem of sophisticated digital services.
The economic significance of this transformation extended beyond the familiar distinction between capital and operational expenditure. Cloud computing changed the relationship between technology investment and organisational uncertainty. Under traditional infrastructure models, enterprises frequently committed capital before knowing precisely how much computing capacity they would require. The cloud made it possible to defer some of those commitments, converting fixed capacity into more flexible consumption. This was particularly valuable for emerging businesses, experimental products and applications experiencing unpredictable demand. The ability to access advanced infrastructure without first constructing or purchasing it also reduced barriers to innovation, allowing organisations to experiment with technologies that would previously have required substantial financial and operational resources.
The intellectual foundations of this model are not entirely new. In his 1937 paper The Nature of the Firm, economist Ronald Coase examined why organisations choose to undertake certain activities internally while purchasing others through markets. His work provides a useful framework for understanding cloud adoption. When external suppliers can deliver a capability more efficiently than an organisation can produce it internally, outsourcing becomes economically rational. Cloud providers benefit from economies of scale, infrastructure standardisation, specialised engineering expertise and the ability to distribute substantial fixed costs across many customers. However, Coase’s broader insight also suggests that the decision between internal provision and external consumption must account for the costs of coordination, contracting and dependency, rather than focusing exclusively on the apparent efficiency of the service being purchased.
This distinction becomes increasingly relevant as cloud environments mature. An organisation may initially experience considerable economic benefits from migrating its infrastructure, only to discover that its operating model has become deeply dependent on the commercial arrangements, technical architecture and pricing mechanisms of its chosen provider. The efficiency of outsourcing therefore needs to be assessed alongside the costs of managing the resulting relationship. What begins as an exercise in reducing operational complexity can gradually become a question of commercial bargaining power, technological flexibility and the organisation’s capacity to respond independently when circumstances change.
The London Outage: A Reminder of the Physical Reality of Digital Infrastructure
The Google Cloud disruption on 20 October 2026 brought these questions into sharper focus. A power-related incident affecting the europe-west2-b availability zone within Google’s London cloud region caused interruptions across numerous services, with wider effects reported within the region. The disruption lasted approximately seven hours and fifty-two minutes according to Google’s incident record, although the timing and extent of customer recovery varied. Financial services organisations, including Revolut, Lloyds and HSBC, reported interruptions, while disruption also affected public services and other digital platforms. Google subsequently confirmed that service availability had been restored and indicated that a detailed incident analysis would follow its internal investigation.
The incident is particularly revealing because the immediate cause was associated with one of the most fundamental requirements of physical infrastructure: electrical power. Despite the sophistication of virtualisation, distributed computing and software-defined architectures, cloud services ultimately depend on physical facilities, energy supplies, networking equipment and operational processes. The language of cloud computing can sometimes encourage the impression that infrastructure has become detached from geography and material constraints. In reality, the abstraction of infrastructure from the customer does not remove the physical dependencies upon which computing relies. It simply places those dependencies within a different organisational and contractual structure.
The broader consequences of the disruption illustrate the importance of distinguishing between a provider’s infrastructure failure and the resilience of the organisations consuming its services. A cloud provider can design sophisticated mechanisms for redundancy and recovery, yet customers must still make architectural decisions about workload placement, data replication, application dependencies and acceptable recovery times. An application deployed within a single availability zone may remain exposed to failures that a properly designed multi-zone architecture could withstand. Equally, an organisation may distribute workloads across multiple zones while retaining dependencies on regional services or shared operational components. The existence of resilient infrastructure capabilities does not guarantee that every application consuming those capabilities has been designed to use them effectively.
The incident should therefore not be interpreted as evidence that public cloud infrastructure is inherently less reliable than privately operated alternatives. Such a conclusion would ignore the substantial engineering investment that hyperscale providers make in availability, redundancy, security and recovery. The more important lesson concerns the distinction between purchasing access to resilient infrastructure and possessing an independently validated resilience capability. Organisations may contract with providers offering sophisticated technical architectures, but their own continuity ultimately depends on how effectively those capabilities have been incorporated into the design and operation of their business services.
The Paradox of Distributed Technology and Concentrated Dependency
One of the defining characteristics of modern cloud computing is its reliance on distributed architecture. Computing resources can be deployed across multiple availability zones, replicated between geographical regions and managed through automated systems intended to reduce the impact of individual component failures. From an engineering perspective, distribution provides an important mechanism for improving availability. However, the economic organisation of the cloud industry has produced a contrasting tendency towards concentration, with a relatively small number of hyperscale providers supplying infrastructure upon which substantial portions of the digital economy depend.
This creates a structural paradox: the technology supporting digital services has become increasingly distributed, while the institutional control of that technology has become increasingly concentrated. Organisations may operate applications across multiple environments and locations while remaining dependent on a common provider’s management systems, identity services, networking capabilities or operational decisions. The distinction between technical distribution and institutional independence is particularly important because the two are frequently treated as equivalent. An architecture can contain considerable redundancy without providing meaningful independence from the failure of a shared underlying dependency.
The implications become clearer when considered through the concept of systemic risk. In conventional enterprise risk management, organisations assess the likelihood and consequences of events affecting their own operations. Systemic risk introduces an additional dimension by examining how a disruption within one component of an interconnected system can affect multiple participants simultaneously. Financial markets provide a familiar example: institutions may appear individually diversified while retaining exposures to common counterparties, funding mechanisms or market conditions. When those shared dependencies become unstable, the apparent independence of the participants can prove misleading.
Digital infrastructure increasingly exhibits comparable characteristics. Financial institutions, retailers, logistics providers and public-sector organisations may maintain separate business models, management structures and operational controls while relying on common technology platforms. A failure within one of those platforms can therefore create correlated disruption across otherwise unrelated organisations. The resulting risk cannot be understood solely by examining the resilience of each organisation in isolation. It requires an understanding of the network of dependencies connecting them, including relationships that may extend through several layers of technology suppliers and managed services.
The critical question is whether enterprises have developed sufficiently sophisticated methods for identifying these dependencies. Traditional supplier assessments may establish that a provider meets contractual, security and operational requirements, yet provide limited visibility into the concentration of services across the wider digital ecosystem. A business may have several technology suppliers and assume that this represents diversification, despite those suppliers relying on the same hyperscale infrastructure. Meaningful resilience assessment therefore requires organisations to look beyond their immediate contractual relationships and consider the underlying architecture of their extended digital supply chains.
Cloud Economics and the Reconsideration of Ownership
The debate surrounding cloud repatriation has introduced another dimension to the reassessment of infrastructure strategy. Repatriation refers to the movement of selected applications or workloads from public cloud environments to privately operated infrastructure, dedicated hosting environments or other deployment arrangements. Its growing prominence reflects a recognition that the economic advantages of cloud computing are not uniform across all workloads or stages of organisational development. Nevertheless, the existence of repatriation initiatives should not be confused with evidence of a wholesale reversal in cloud adoption.
The economic rationale for public cloud is particularly strong where demand is variable, infrastructure requirements are uncertain or organisations benefit from rapid access to managed services. By contrast, predictable workloads operating at consistently high utilisation may exhibit different cost characteristics. Where computing demand remains relatively stable, the premium associated with flexible consumption can become more significant over time. Organisations may also encounter costs associated with data transfer, storage, licensing, networking and the continued operation of resources that are no longer fully utilised.
Flexera’s 2026 State of the Cloud research illustrates the persistence of these financial management challenges. Its findings identify cloud cost management as a leading concern among respondents, with organisations continuing to report substantial estimated waste in cloud expenditure. Such findings should not be interpreted as proof that private infrastructure would necessarily be cheaper. They do, however, demonstrate that the economic efficiency of cloud consumption depends on active governance, workload optimisation and an accurate understanding of the relationship between resource utilisation and business value.
The comparison with on-premise infrastructure is consequently more complicated than a simple examination of monthly cloud expenditure against the purchase price of servers. Privately operated environments involve capital costs, maintenance, facilities, energy consumption, staffing, security, resilience arrangements and the risk of technological obsolescence. Cloud environments introduce different financial considerations, including consumption variability, commercial commitments, service dependencies and potentially significant switching costs. A rigorous assessment must therefore consider the total economic lifecycle of a workload, including the cost of maintaining the flexibility to change its deployment model.
There is also an important distinction between cost efficiency and strategic efficiency. An infrastructure arrangement may minimise immediate expenditure while increasing exposure to future pricing changes or limiting an organisation’s negotiating position. Conversely, maintaining independent infrastructure capabilities may appear more expensive in narrow accounting terms while providing valuable flexibility in procurement, regulatory compliance or business continuity. Infrastructure economics should therefore be understood as an optimisation problem involving cost, risk, flexibility and control, rather than a competition between two supposedly universal pricing models.
From Outsourced Operations to Retained Accountability
The relationship between outsourcing and accountability is perhaps the most consequential aspect of the cloud debate. When organisations purchase infrastructure services from external providers, they transfer responsibility for significant operational activities, including the maintenance of physical facilities and substantial elements of the underlying technology stack. They do not, however, eliminate their obligations to customers, regulators, shareholders or other stakeholders. The distinction between delegated operational responsibility and retained institutional accountability is particularly important in sectors where digital service continuity has direct economic or social consequences.
The regulatory response to technology concentration reflects growing recognition of this problem. In July 2026, the Bank of England, Prudential Regulation Authority and Financial Conduct Authority began overseeing the first four technology providers designated as critical third parties under the United Kingdom’s new regulatory framework. These included Google Cloud, Amazon Web Services, Microsoft and Oracle. The framework recognises that disruption affecting a major technology provider can create risks extending across multiple financial institutions and potentially threaten the stability of services relied upon by consumers and businesses.
The European Union’s Digital Operational Resilience Act provides a related example of regulatory attention to technology dependencies within financial services. Its framework addresses information and communication technology risk, operational resilience testing, incident management and the oversight of critical third-party providers. The significance of these developments is that technology outsourcing is increasingly being examined not merely as a procurement decision, but as a potential source of systemic exposure. The regulatory focus has expanded from whether an individual institution manages its technology suppliers appropriately to whether concentrations of dependency could produce disruption across an entire sector.
The timing of the London outage is notable in this context. On 21 October, Reuters reported that European financial regulators were seeking information from Google concerning the disruption and its consequences for financial institutions. The incident therefore provides an early practical test of the regulatory attention being directed towards hyperscale technology providers. It also reinforces the principle that organisations remain responsible for managing their own continuity arrangements, even where the immediate source of disruption lies within an external provider’s infrastructure.
This presents a governance challenge for boards and executive leadership teams. Technology outsourcing can create an apparent separation between strategic decision-making and the operational systems upon which those decisions depend. Senior leaders may understand the commercial rationale for cloud adoption without possessing an equally detailed understanding of the failure scenarios embedded within their technology architecture. Effective governance requires that this gap be addressed through clear accountability, appropriate technical assurance and meaningful evidence that critical business services can withstand foreseeable disruption.
The Case for On-Premise Infrastructure Revisited
The renewed interest in on-premise infrastructure is understandable, particularly among organisations managing sensitive data, predictable computing demand or demanding operational requirements. Direct control over infrastructure can provide greater flexibility in certain aspects of configuration, access management, hardware selection and operational scheduling. It may also reduce exposure to some forms of provider-specific dependency and enable organisations to maintain systems that are deliberately isolated from external connectivity.
However, ownership should not be mistaken for resilience. Privately operated data centres remain exposed to equipment failures, power interruptions, security incidents, network disruption and human error. They also require sustained investment in maintenance, technical expertise and recovery capabilities. An organisation that relocates a critical application from public cloud to a single privately operated facility may simply exchange one concentration risk for another. The location of the infrastructure changes, but the underlying challenge of designing for failure remains.
The strongest argument for reconsidering on-premise infrastructure is therefore not that it is inherently superior to public cloud. It is that organisations should retain the ability to select deployment models according to the characteristics of their workloads and the consequences of their failure. Certain systems may benefit from the elasticity and sophisticated managed services available through hyperscale platforms, while others may justify dedicated infrastructure because of their utilisation patterns, latency requirements, regulatory obligations or need for operational independence.
This approach also requires a more precise understanding of sovereignty. Data residency, infrastructure ownership and operational control are related but distinct concepts. Hosting data within a particular national jurisdiction does not necessarily provide complete independence from external service providers, contractual arrangements or technology supply chains. Equally, owning physical infrastructure does not automatically establish control over the software, hardware components or specialist services required to operate it. Sovereignty is better understood as a combination of legal authority, technical capability, operational competence and the practical freedom to make and implement independent decisions.
The Limits of Multi-Cloud as a Resilience Strategy
Multi-cloud adoption is frequently proposed as a solution to hyperscaler concentration, based on the assumption that using multiple providers reduces dependency on any single organisation. There is merit in this proposition where workloads can operate independently across providers and where recovery mechanisms are properly designed and tested. Nevertheless, multi-cloud architectures introduce additional complexity, and the presence of multiple suppliers should not be regarded as sufficient evidence of resilience.
Applications distributed across different providers may still rely on shared identity systems, common network connections, centralised monitoring platforms or a single source of operational expertise. The failure of one such component can undermine the apparent independence of the wider architecture. Organisations may also discover that replicating applications across different cloud platforms requires significant investment in engineering, data synchronisation, security management and operational coordination.
A more rigorous approach begins with the identification of failure domains: the components, systems or operational dependencies that could be affected by a common disruptive event. Resilience can then be designed around the consequences of losing those dependencies, rather than around the number of cloud providers represented in the technology estate. For some organisations, a carefully engineered multi-zone or multi-region architecture within one provider may offer a more appropriate balance of reliability and cost than a complex multi-cloud arrangement. For others, particularly those supporting critical national or financial services, independent provider capabilities may be justified by the potential consequences of correlated failure.
The effectiveness of either approach depends on demonstrable recovery capability. Business continuity arrangements that exist only in documentation provide limited assurance. Organisations need to understand whether applications can actually be restored, whether data remains accessible, whether operational teams possess the necessary expertise and whether recovery can occur within the timeframes required by the business. The distinction between designed redundancy and tested resilience is essential because technological complexity can otherwise create confidence that has not been validated under realistic conditions.
Artificial Intelligence and the Next Infrastructure Settlement
Artificial intelligence introduces further complexity into the relationship between cloud consumption and infrastructure ownership. Advanced AI workloads require substantial computing resources, specialised accelerators, high-performance networking and increasingly significant energy capacity. Hyperscale providers offer access to capabilities that would be difficult for many organisations to reproduce independently, making public cloud an important enabler of AI development and deployment.
At the same time, AI introduces workload characteristics that may alter the economics of infrastructure decisions. Continuous inference workloads, specialised model deployments and applications requiring predictable low-latency performance may justify dedicated capacity under certain conditions. Organisations processing highly sensitive information may also place greater emphasis on data governance, model control and deployment flexibility. The appropriate infrastructure model will depend on the relationship between utilisation, technical requirements, capital availability and the strategic importance of the underlying AI capability.
There is a broader economic consideration. As computing capacity becomes increasingly important to organisational competitiveness, access to infrastructure can influence the ability to innovate. Dependence on a limited number of technology providers may affect commercial bargaining power, deployment options and the speed at which organisations can adapt their AI strategies. Infrastructure decisions consequently become intertwined with questions of technological autonomy and competitive positioning.
The emergence of AI does not make a return to privately owned infrastructure inevitable. It does, however, reinforce the importance of maintaining strategic optionality. Organisations capable of evaluating and adopting different infrastructure models may be better positioned to respond to changes in computing economics, regulatory expectations and technological capabilities than those committed to a single deployment philosophy.
Towards Architecture-First Thinking
The most constructive response to the current debate is to move beyond the assumption that infrastructure strategy should be organised around a preferred technology model. Cloud-first thinking served an important purpose by challenging traditional approaches to infrastructure ownership and encouraging organisations to exploit the advantages of scalable, programmable services. Its limitations become apparent when the preference for cloud deployment begins to precede a proper assessment of workload characteristics, business consequences and organisational requirements.
An architecture-first approach would reverse that sequence. Decisions would begin with the strategic importance of the service, its economic characteristics, the consequences of interruption, the regulatory environment and the degree of operational independence required. Deployment models would then be evaluated according to their ability to satisfy those requirements. Such an approach does not diminish the importance of public cloud; rather, it places cloud computing within a broader framework of enterprise decision-making.
The concept of optionality provides a useful intellectual foundation for this framework. In financial theory, options have value because they preserve the ability to respond to future circumstances without requiring an immediate irreversible commitment. A similar principle applies to infrastructure architecture. Organisations that can relocate workloads, recover services independently, access their data and negotiate alternative supplier arrangements retain flexibility that may become valuable when economic, regulatory or operational conditions change.
However, optionality is not free. Designing every application for complete portability can introduce substantial cost and prevent organisations from exploiting the benefits of specialised cloud services. The objective should therefore be proportionate optionality, where the investment required to preserve alternatives is justified by the strategic significance of the workload and the potential consequences of dependency. This is a more sophisticated proposition than either universal cloud adoption or universal infrastructure ownership because it recognises that different systems warrant different levels of independence.
The practical implication is that infrastructure architecture should become a more explicit component of enterprise strategy. Boards should understand not only the financial cost of their technology arrangements but also the dependencies those arrangements create, the alternatives available and the organisation’s capacity to respond when a critical service becomes unavailable. Technology leaders, in turn, should be able to explain infrastructure choices in terms of business outcomes rather than platform preferences.
Are We Going Full Circle?
The temptation to interpret recent cloud disruptions as evidence of a return to on-premise infrastructure is understandable, particularly given the cyclical nature of technology adoption. Enterprise computing has repeatedly moved between centralised and decentralised models, from mainframes and client-server architectures to virtualised data centres and hyperscale cloud platforms. Each transition has reflected changing relationships between computing economics, technological capability and organisational requirements.
Nevertheless, the present moment is not simply a repetition of an earlier phase. The technological environment has changed substantially, as have the scale of digital interdependence, the sophistication of cloud services and the economic importance of continuous connectivity. A wholesale return to privately owned infrastructure would fail to capture the advantages created by cloud computing, just as unquestioning commitment to cloud-only strategies would neglect the legitimate concerns surrounding dependency and control.
The more persuasive interpretation is that enterprise infrastructure strategy is entering a period of reassessment in which the original benefits of cloud computing are being considered alongside a more developed understanding of their associated trade-offs. The emphasis is shifting from whether organisations can migrate workloads to the cloud towards whether their chosen architectures provide the appropriate combination of efficiency, resilience, flexibility and accountability.
The London Google Cloud outage is significant not because it invalidates the cloud model, but because it demonstrates how the operational failure of a shared technology platform can expose dependencies across otherwise independent organisations. It reminds us that the economic benefits of abstraction do not eliminate the physical realities of computing, and that the delegation of infrastructure operations does not remove an organisation’s responsibility for the continuity of its services.
Perhaps the most important conclusion is that the next stage of enterprise technology maturity will be defined less by the location of infrastructure than by the quality of the decisions governing it. Organisations will need to become more deliberate about where they accept dependency, where they require independence and how they balance the cost of resilience against the consequences of failure. Public cloud, private infrastructure and hybrid architectures will continue to play important roles, but their value should be determined by strategic suitability rather than ideological preference.
We may not, therefore, be going full circle in the conventional sense. What appears to be a return to earlier questions about ownership and control may instead represent a deeper understanding of the relationship between technology and organisational autonomy. The cloud revolution changed how enterprises acquire and operate computing infrastructure. The next evolution may concern how intelligently they govern the dependencies that transformation has created.
The real measure of infrastructure maturity is not how successfully an organisation has transferred responsibility for operating its technology, but how effectively it has preserved its capacity to operate, adapt and make independent decisions when the systems upon which it depends are disrupted.
That is the question I believe deserves greater attention in the boardroom, in enterprise architecture discussions and across the wider technology industry.
Research and editorial references
The article draws on contemporary reporting and primary sources, including:
- Google Cloud — London incident record, documenting the affected region and service disruption.
- Reuters — 20 October 2026, reporting the effects on financial institutions and public services.
- Reuters — 21 October 2026, covering the European regulatory response.
- Bank of England — Critical Third Parties oversight, setting out the UK’s new regulatory framework.
- Ronald Coase, The Nature of the Firm (1937), providing the economic foundation for the discussion of organisational boundaries, outsourcing and transaction costs.
- Flexera, 2026 State of the Cloud Report, informing the discussion of cloud financial management and cost optimisation.
#StellasLens #CloudComputing #CloudStrategy #EnterpriseArchitecture #DigitalResilience #InfrastructureSovereignty #HybridCloud #CloudRepatriation #TechnologyLeadership #OperationalResilience
Discover more from Stella Poole
Subscribe to get the latest posts sent to your email.
