Mind the Gap: Closing the Expectation Divide in Cloud & Data Center Services

Global demand in cloud computing industry and data centers is growing faster than ever. There is an explosion of hyperscalers as well as AI workloads that provide unprecedented growth impetus; companies at every level depend on providers to maintain high-performance networks. Yet amid all its innovation and growth, though, one thing is unchanged: the difference between what service agreements promise and what customers expect.

Uptime: The One-Way Street of Gratitude

The majority of professional hosting and cloud agreements make an uptime priority minimum (generally 99.95% and up) for essential network and infrastructure. 99.95% is perfect for the average joe, but in practice it allows for almost 4½ hours of downtime a year. Here’s the paradox: if a provider provides flawless service for years, no one writes a thank-you note. The silence on success is just “business as usual.” But then for 5 minutes when a blip happens … still well under 99.95% of the promise … customer support lines light up and legal clauses get quoted back to the provider. It’s not the case of customers being ungrateful, the lesson is that reliability has been rendered invisible. Uptime is required, and any deviation, no matter how slight or contractually permissible, is regrettable.

Backups: The Unpaid — and Often Misplaced — Safety Net

And the other consistent rub is backup accountability. Many customers of the cloud and bare-metal world think data can be automatically backed up when it resides at a professional data center. In practice, much of the standard agreement does not provide protection for data but access to the essential infrastructure. When a virtual machine fails or a dedicated server’s disk dies, infrequent but inevitable events, customers without a backup plan often require that the provider “just recover it.” And unless backups were part of the contract (or bought as an add-on), the provider can’t magically restore lost data. Another common yet sometimes ignored rule: You don’t have backup and recovery if you don’t pay for them. Customers can and should be told and are supposed to be educated by providers, but the responsibility of protecting data integrity falls to the data owner.

Backups on the Same Server: A Concealable Catch

Even customers who maintain backups can fall into the trap of storing those backups on the same VM or dedicated server they’re trying to protect. When the underlying hardware fails, it means that both the live data and the “backup” could disappear in a single stroke. Real resilience is holding backups offsite or at least on different physical infrastructure — in another availability zone, on another storage platform or through a managed backup service. A backup that shares the same failure domain isn’t a backup at all; it is simply yet another copy waiting to fail.

Planned Maintenance: No Good Deed Goes Unpunished

Even infrastructure most reliably established requires care. Hardware firmware ought to be patched, network gadgets upgraded, and security equipment put to the latest security updates. Nearly every service agreement specifies the timing of scheduled maintenance windows, and providers generally work on those days in the dead of night with ample notice given. Yet maintenance notices regularly provoke resistance. Some customers need zero disruption at any cost, including when the work is needed to prevent future outages. Ironically, the clients who value stability can be hostile to the very processes needed to preserve it.

Bridging the Expectation Gap

So how do providers and customers come together in the middle?

Crystal-Clear SLAs

Service Level Agreements need to be written in plain language, specifying uptime objectives, response times, and — crucially — what is not included. Define roles for backups, recovery and data retention.

Proactive Education

Providers should communicate the reality of uptime %, needs for maintenance, and responsibilities for backups during the sales process, not after the fact.

Shared Responsibility Models

When you hear the term shared responsibility, public cloud behemoths such as AWS and Azure made it famous. The former way, (whether that be infrastructure-as-a-service (IaaS) or colocation), is that the provider maintains the platform, while the customer secures and backs up their data.

Celebrate Reliability

It might seem a little self-obsessed, but frequently appearing as reports of “X days of uninterrupted service” help remind subscribers of what they’re getting back — and can help soften feelings when an unavoidable event plays out.

Not a Transaction, a Partnership

A data-center / cloud agreement is a partnership in its simplest form. Providers agree to world-class uptime, redundancy, and security; clients agree to gauge the extent of those services and plan. And when each side sees the contract as a living document and not fine print, there’s less room for surprise and fewer panicking calls when the inevitable hiccup occurs.

Takeaway: That is, nothing about the world-defining infrastructure is ever “set and forget.” Transparency is the key to successful customer relationships: explicit SLAs, contracts of mutual responsibilities, and an understanding that when it comes to maintenance, backups (carried out in their own locations) and periodic downtime, the system is better for it. Finally, a strong provider is not someone who never does need to worry about a problem, but one who talks things over openly, keeps promises and works with customers to navigate the times when the lights go out.

#CloudComputing #DataCenters #SLA #Uptime #Downtime #CloudServices #Infrastructure #DevOps #ITOperations #ServiceLevelAgreement #HighAvailability #CloudReliability #CloudBackup #PlannedMaintenance #BusinessContinuity

https://www.linkedin.com/pulse/mind-gap-closing-expectation-divide-cloud-data-center-andris-gailitis-wo94f

When the Cable Snaps: Why Regional Compute Can’t Be an Afterthought

It is a web of glass threads lying on the seabed. Twice, in starkly different seas, those threads were cut.

cable
compute
undersea

Two *subsea cables** in the Baltic Sea were cut within hours of one another in November 2024, cutting capacity across Finland, Lithuania, Sweden, and Germany.

In *September 2025**, multiple systems in the Red Sea, one of the world’s busiest internet corridors, were damaged and services were decimated across Europe, the Middle East, and Asia.

Each event had its own cause, but the net effect for users, enterprises, and cloud providers was the same: latency spikes, rerouting stress, an unpleasant lesson that our digital lives rely on a handful of physical chokepoints.

## The myth of infinite bandwidth

It is easy to assume “the cloud” will just absorb disruptions. Microsoft and AWS do have very good redundancy, and traffic was rerouted. But physics can’t be abstracted away:

*Latency increases** when traffic takes the bypass thousands of kilometers.

*Throughput decreases** when alternative routes inherit workloads.

*Resilience shrinks** when other cables in the same geography break down.

For latency-sensitive services — trading platforms, multiplayer gaming, video collaboration — the difference between 20 ms and 150 ms is the difference between usable and unusable. Because compliance-heavy workloads must reroute into areas with unknown jurisdictions, this carries very different risks of its own.

Regional compute is the antidote

The lesson is that if enterprises don’t want to expose themselves to chokepoints, regional compute capacity will have to be closer to both users and data sources. Regional doesn’t just mean “they’re all on the same continent.” And those operations must remain so they can continue if a submarine cable was cut and important international routes were taken offline. Regional compute operates in three aspects:

1. Continuity of performance – Maintain fast and stable mission-critical applications when cross-ocean fault paths are broken.

2. Risk diversification – Eliminate dependence on a single corridor — Red Sea, Baltic Sea, English Channel, etc.

3. Regulatory alignment – For some jurisdictions, including the EU, managing data within borders deals with sovereignty requirements as well.

## Europe as a case study—sovereignty through resilience

Europe’s movement for “digital sovereignty” (see NIS2, the EU Data Boundary, AWS’ European Sovereign Cloud…) is frequently presented in terms of compliance and control. But the cable incidents illustrate a more common principle: keeping capacity local is a resilience measure first, a regulatory checkbox second.

If you’re working inside the EU, sovereignty is one factor. If in Asia, the reasoning is similar — no need to rely on Red Sea transit. In North America, resilience might look like investing in a variety of east–west terrestrial routes to protect against coastal chokepoints.

A global problem with regional solutions

Route disruptions, by natural catastrophes, ship anchors, or even deliberate sabotage, have struck the Atlantic, Pacific, and Indian oceans. Every geography has its weak spots. That’s why international organizations are now more and more wondering: Where can we compute if the corridor collapses?

The answer frequently isn’t another distant hyperscale region. It’s:

*Regional data centers** embedded in terrestrial backbones.

*Local edge nodes** for caching and API traffic.

*Cross-border clusters** of real route diversity, not just carrier diversity.

## Building for the next cut

Here’s what CIOs, CTOs, and infrastructure leaders can do:

1. Map your exposure. Do you know which subsea corridors are mostly under your workload? Most organizations don’t. Ask for path transparency from your providers.

2. Design for “cable cut mode.” Envision what happens if the Baltic or Red Sea corridor goes dark. Test failover, measure latency, and revise the architecture accordingly.

3. Invest regionally, fail over regionally. Don’t just copy and paste data cross-sea. Build failover in your own core market when possible.

4. Contract for resilience. Diversity in routes, repair-time commitments, regional availability — build these into your SLAs.

5. Frame it as business continuity. This is not only a network ops situation, it’s a boardroom problem. One day of degraded service can exceed the cost of additional regional capacity.

Beyond sovereignty

Yes, sovereignty rules in Europe are a push factor. But sovereignty alone doesn’t explain why a fintech in Singapore, a SaaS in Toronto, or a hospital network in Nairobi would care about regional compute. They should care because cables are fragile, chokepoints are real, and physics doesn’t negotiate.

The bottom line

Last year’s cable cuts weren’t necessarily catastrophic. They were warnings. And the world’s dependence on a few narrow subsea corridors is increasing, not decreasing. As AI, streaming, and cloud adoption accelerate, the stakes rise.

Regional compute isn’t all about sovereignty. It’s about resilience. The organizations that internalize that lesson right now—before the next snap—will be the ones that stay fast, compliant, and reliable while others grind to a halt.

Subscribe & Share now if you are building, operating, and investing in the digital infrastructure of tomorrow.

#SubseaCables #CableCuts #DigitalResilience #RegionalCompute #DataCenters #EdgeComputing #NetworkResilience #CloudInfrastructure #DigitalSovereignty #Latency #BusinessContinuity #NIS2 #CloudComputing #InfrastructureSecurity #DataSovereignty #Connectivity #CriticalInfrastructure #CloudStrategy #TechLeadership #DigitalTransformation

https://www.linkedin.com/pulse/when-cable-snaps-why-regional-compute-cant-andris-gailitis-we9sf

AWS, Azure, and Google Cloud vs. Everyone Else: What Truly Makes Them Different

When people speak of “the cloud,” they tend to refer to the big three: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). Together, they control more than two-thirds of the global market. But they are not the whole picture. And smaller providers — Oracle, IBM, and Alibaba to regional and niche players like OVHcloud, Hetzner, Scaleway, DigitalOcean, and Wasabi — are continuing to expand by providing something different.

So what actually distinguishes the hyperscalers from others? And what might lead organizations — predominantly in Europe — to hesitate to double down on the big three?


1. Scale and Global Reach

  • AWS, Azure, GCP:
  • Other providers:

👉 Tip: If your business is truly global, hyperscalers prevail. If you are region-specific, a specialist provider may be more effective.


2. Breadth of Services vs. Complexity

  • AWS, Azure, GCP:
  • Other providers:

👉 Lesson: Big clouds do mean you can be innovative but can also be dependent. Smaller providers give you focus and flexibility.


3. Pricing and the Illusion of Cheap

  • AWS, Azure, GCP:
  • Other providers:

💡 Key Takeaway: Hyperscalers are nearly always more expensive than managed hosting or hardware-for-rent models in Europe. Renting bare-metal servers with managed services can deliver similar performance at a lower TCO — without paying for unused features.


4. EU Regulation and Sovereignty

Now this gets political.

  • The EU’s Data Act and AI Act aim at guaranteeing digital sovereignty. However, most European enterprises still host sensitive workloads on U.S.-controlled hyperscalers.
  • Under the U.S. CLOUD Act, American companies can be compelled to hand over data, even if it’s stored in Europe. This creates legal uncertainty around banks, governments, and healthcare providers in the EU.
  • So European regulators and CIOs increasingly view reliance on U.S. clouds as a sovereignty risk.

Smaller European providers (OVHcloud, Scaleway, Deutsche Telekom’s Open Telekom Cloud) are picking up on this by ensuring data stays in Europe and is governed by European law.


5. The Lock-In Problem

It’s simple. You can get onto a hyperscaler with migration tools, free credits, and onboarding teams.

But getting off? That’s where the trap lies.

  • Proprietary databases, AI frameworks, serverless functions, and APIs don’t necessarily move.
  • Egress fees (paying to get your data out of the cloud) create financial barriers.
  • Complicated contracts and enterprise agreements bind customers for years.

👉 Once you’re deep into AWS, Azure, or Google Cloud, re-engineering workloads toward on-prem or moving to another provider is almost impossible.


6. Compliance and Industry Fit

  • Hyperscalers:
  • Other providers:

7. Innovation vs. Specialization

  • AWS, Azure, GCP:
  • Other providers:

The Strategic Choice

So what do decision-makers need to think about?

  • If you need global scale and advanced services, hyperscalers are unmatched.
  • If you want predictability, sovereignty, and lower costs, regional providers or managed hosting often win.
  • For some, the answer is a multi-cloud or hybrid approach: run AI workloads on a hyperscaler, hold sensitive or critical data with a sovereign provider, and use managed hosting for cost-sensitive workloads.

Final Thoughts

The big three clouds are powerful — but they come with strings attached: higher costs, lock-in, and sovereignty risks. Smaller and regional providers offer simpler pricing, local compliance, and more freedom.

In Europe in particular, the debate isn’t merely technical — it is political. Depending entirely on U.S. hyperscalers may solve today’s scaling problems, but it poses long-term risks to sovereignty and independence.

💡 Takeaway for business leaders: Don’t just ask “Which cloud is the biggest?” Ask “Which cloud best aligns with my strategy, compliance, and sovereignty needs?” The best choice might be a well-balanced one.

Subscribe & Share now if you are building, operating, and investing in the digital infrastructure of tomorrow.

#Cloud #AWS #Azure #GoogleCloud #MultiCloud #DataSovereignty #EUAIAct #CloudAct #DataCenters #ManagedHosting #DigitalSovereignty #LockIn #FinOps #AI #Infrastructure

https://www.linkedin.com/pulse/aws-azure-google-cloud-vs-everyone-else-what-truly-makes-gailitis-kfukf

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑