- Google said a "power event" hit its London europe-west2 region. InfoWorld columnist David Linthicum says it reached banks, delivery services, some NHS app services and court video links.
- The sources do not show whether any affected service was poorly designed. Linthicum argues that the provider runs the platform and the customer decides how its software is laid out on it.
- Ask teams to label each dependency of the three most costly systems as zonal, regional or global, price one hour of downtime for each, and show when a restore was last tested.
What the sources do and do not tell us
A cloud outage invites a quick verdict: the customers should have built it better. The sources do not support that verdict. They do not show whether any affected service ran in one region, was poorly designed or was well protected.
This story uses the London incident to examine an argument by InfoWorld columnist David S. Linthicum. His piece is an opinion column, not an incident report.
Google said a "power event" hit London data centers in its europe-west2 region. Linthicum says banks, delivery services, e-bike providers and budgeting apps were caught up. He adds that some National Health Service app appointment services and court video-link systems were too.
The column gives no outage length, customer count or detailed cause beyond Google's "power event". Google later reported that most affected workloads were running again. A small number of customers still had problems.
Three sizes of failure: zone, region, global
Cloud services come in three sizes. A zone is one isolated slice of a provider's infrastructure. A region is a geographic cluster of zones. Some services are global and are not tied to one place.
Linthicum says a resilience program should sort services by these sizes. He also asks which depend on the provider's control plane. That is the management layer that creates and changes cloud resources.
Here is the point we would add. Each size is a different question for your teams, and each needs a different kind of answer.
For a zonal service, ask whether a second zone is really running and carrying load. For a regional service, ask what happens when the whole region goes. Do you have a copy elsewhere, and who decides to switch? For a global service, ask what you do if the provider's own layer is the part that fails.
A diagram that shows servers in several zones answers only the first question. It says nothing about the other two.
How one regional fault could reach unrelated services
Consider a hypothetical online retailer. This is an illustration, not a description of any affected organisation. Its web servers run across several zones in one region. On a diagram, that looks safe.
Suppose its login service sits in that region. Healthy servers elsewhere cannot let customers sign in. Suppose its order database is regional too. Nothing can be read or saved.
Now suppose the payments company it calls runs in the same region. Card payments fail. The monitoring tools sit there as well, so staff cannot see what is wrong. Linthicum lists each of these as a way a seemingly resilient design can fail.
Each part looks separate on the diagram. In a fault, they could fail together. This describes a possible mechanism, not the confirmed cause of the London disruption. It shows how services that look unrelated could be hit on the same day. Linthicum says they may share providers, regional infrastructure, networks, identity systems and APIs. An API is the way one program calls another.
What to do differently on Monday
Linthicum's wider point is that providers sell building blocks, such as regions, zones, replication and backups. He says these are not a finished strategy. In his framing, the provider keeps the platform running and the customer owns the layout on top.
The practical change is to stop asking whether a system is in the cloud. Ask which size of failure it can survive, and who has proved it. Moving out of a company data center can swap one single point of failure for another. The platform improves. The layout may not.
Start with the three systems that hurt most when down. Have each team label every dependency, including login, DNS and third-party services, as zonal, regional or global. A third-party service that runs in the same region as your own counts as the same risk.
Then ask for a price. Linthicum suggests counting lost sales, contract penalties, regulatory exposure and the cost of manual workarounds for one hour of downtime.
Last, ask for proof. When was a restore from backup last tested, and how long did it take? Who can approve a failover, and do they have the access to do it? Linthicum says drills often expose these gaps in people and permissions, not in the platform.
Multicloud is not the automatic answer
After an outage, many people call for multicloud, meaning two or more providers. Linthicum says that is sometimes right but often "an expensive distraction". Without duplicated architecture, copied data, shared security rules and skilled staff, he writes, it becomes "distributed fragility".
He prefers protection matched to the workload. Some systems need several regions at one provider. Others need a standby copy, or just reliable backup and restore. A few can accept hours of downtime.
Pricing the protection
Better resilience costs money. Linthicum notes that several regions, replicated databases, extra monitoring and test environments all raise cloud spend. Some systems will justify that once downtime has a price. Others will not.
What he warns against is "accidental underinvestment". That is a business-critical system left weak only because nobody priced the risk. A provider can bring a data center back. Only you can decide how much of the business keeps running meanwhile.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: InfoWorld.
