Hacker News Reader

Comment by bjackman | Hacker News Reader

> You are unlikely to change cloud providers, so choose one and stick to it. Use their managed features.

I am curious about this because I see opposing views expressed by different people. I have never personally been in a position where the decision has been relevant.

I work at a cloud provider an I'm told that a big slice of our revenue comes from customers who are already load-balancing across multiple clouds, so if we degrade perf/dollar they just turn a dial to shift load to our competitors.

This has always seemed very smart to me and I would love to get more perspectives on how easy it is to get to that position where your infrastructure is so commoditised that you can migrate between providers and back at the push of a button.

Is this something people achieve late in their lifecycle after massive cost-optimisation push? Or is this actually something you can build towards from day 1?

View on HN

> I work at a cloud provider an I'm told that a big slice of our revenue comes from customers who are already load-balancing across multiple clouds, so if we degrade perf/dollar they just turn a dial to shift load to our competitors.

It's only anecdata but I'd highly question that. All companies I worked in (startup, midsize, megacorps) went with one cloud provider and stick to it. That is also not only my experience but also from friends who work in the same field. There might be a slight difference with megacorps where I saw them using multiple cloud providers but more like: Team A is using AWS, Team B is using GCP. But never: Team A is using AWS and has a copy running, ready to go, on GCP.

I tend to agree with the GP, to a degree. Chose an cloud provider and stick with it, the probability that the company changes the provider is very low (in the end all cloud provider offer the same with similar prices, no need to switch) but don't fully buy in. Like if you're on AWS, of course use RDS for DB and S3 for object storage but don't use Code Pipelines to build. So don't go "fully" proprietary.

i think it’s likely to be a certain class of customer, rendering or high power batch processing. These are relatively simple, pull a task off a stack and crunch for 90 mins, then dump the results in a bucket workloads. Large volume customers that will represent a disproportionate bottom line value to a cloud provider. Probably not the customers you are talking about above

> I am curious about this because I see opposing views expressed by different people.

My sample size is me and my immediate friends. I suspect that if you have a resilient multi-cloud deployment, then you'll use it to hunt for a metric you want to hit (speed/price/latency)

However, the engineering cost to get there is pretty high, and almost negates the point of having the cloud (unless you have a scaling requirement where you need 10x at short notice.)

I worked at a large news company, and it was decided that it was cheaper to just pay for the hosted services than pay for the people to run them (think RDS vs home grown DB) RDS is what 2x the cost of a normal instance, but thats still cheaper than the three engineers + oncall to manage a custom deployment and manage the backups and migrations. (along with conway's law of having DBAs)

Reply on news.ycombinator.com