Hacker News Reader

Comment by vivzkestrel | Hacker News Reader

Instead we need a startup that builds over every cloud provider. Think of a web server for example. AWS has EC2, GCP has its own equivalent and Azure has its own and so on. What if we had a startup that virtualizes a layer on top of these such that we AWS has an outage, you lose 1/3rd of your operating capacity, when Azure has an outage you lose 1/3rd of your operating capacity. In order for you startup s virtual webserver to go down, all of AWS, GCP and Azure wil have to go down simultaneously. Basically build on top of everyone s cloud service into one single unified virtual layer that offers end products to consumers. A 6GB RAM server that the end consumer purchases has 2GB of RAM running on AWS, 2GB on Azure and 2GB on GCP. I am sure we can also strategize something along the same lines for a database server with the added question of the database sharding strategy at play

View on HN

This is what Fog and other cloud agnostic libraries promise. The problem is they you get tied to the lowest common feature set or writing different code paths to take advantage of latest features.

In practice, you're better off just having one cloud but if you ever reach the point you care about this, you're better off running some cloud-agnostic platform like Kubernetes in a multi-cloud setup (i.e. one cluster per cloud) and then load-balancing or failing over via DNS.

It's great in theory, it's just relatively expensive. You'll need to pay to be running on all the clouds plus keeping extra traffic to keep databases synced. Distributed systems are hard.

> What if we had a startup that virtualizes a layer on top of these such that we AWS has an outage, you lose 1/3rd of your operating capacity, when Azure has an outage you lose 1/3rd of your operating capacity.

And then when your startup goes down we lose 3/3rds of our operating capacity!

---

There are certain kinds of errors and failures that it's not worth protecting against, because the costs (and consequences) are more than just accepting that things fail from time to time.

It's easy to forget that services used to go down all the time in the 1990s and early 2000s. In this case, we still have super-impressive resiliency with modern cloud hosting.

IMO: The best way to improve the situation is for the cloud hosts to take their lessons learned and improve themselves, and for us (their customers) to vote with our feet if/when a cloud provider has problems.

> A 6GB RAM server that the end consumer purchases has 2GB of RAM running on AWS, 2GB on Azure and 2GB on GCP.

That'd be very inefficient usage of compute. Memory access now has network latency, cache locality doesn't exist, processes don't work. You're basically subverting how computers fundamentally work today. There's no benefit.

I know Kubernetes and containers has everyone thinking servers don't matter but we should have less virtualization, not more. Redundancy and virtualization are not the same thing.

Many (most) companies don’t even manage to split their application across multiple cloud regions with the same provider. Doing it across providers is an order of magnitude harder.

Reply on news.ycombinator.com