Comment by endymi0n | Hacker News Reader

Comment by endymi0n | Hacker News Reader

No questions on the technical implementation, this looks impressive. Nevertheless, I'm getting more and more convinced that the whole multi-cloud topic is snake oil, an engineering self-purpose and basically the ORM discussion of the '00 years reloaded.

When you're betting on any of the large, public clouds, what you're paying extra on top compared to colocation is basically renting an insanely large and experienced operations team that's solely incentivized by keeping the services running and connected. I'm not saying the large players will never fail, but at least they are designed and built to that standard at any single point of contact.

Even at a _single_ public cloud, bugs and misconfigurations far outweigh any hardware failure. I've seen routing configurations or the Kubernetes backplane fail on GCP that took down my services, but never ever even a whole Availability Zone.

The farther you zoom out, the larger the probability of misconfiguration and failure by excessive technological complexity compared to individual server or service failure.

I did myself a favor once and wondered what's the actual cost if our site goes down and for how long. Surely it's high, you might be surprised to actually compare that against what you're paying for in risk management.

With that number in hand, I decided for example that the risk and adjusted cost of whole AZ failure is negligible compared to what we were paying for in intra-AZ traffic and happily put all of our production network back into one AZ (backups excluded of course).

Also, on the cost side, you'll usually get larger discounts and massively save on traffic costs if you just bet on a single cloud that should far outweigh any savings you might get by the leverage of avoiding lock-in, or buying individual services cheaper on specific clouds.

Then again, we're not servicing any life critical systems. Your mileage may vary.

Regardless of multi-cloud deployment preferences, multi-cloud readiness has tremendous value in itself.

Biggest of the values is having the freedom and choice to pack up from one cloud and go to another at the drop of hat.

Another equally important reason is to provide some commoditization of cloud providers so they don't grow all powerful.

It also keeps cloud market open for new entrants that can come in with better/different value propositions than the existing players and stand a fighting chance of playing upon merits.

Unless you (as in general developer and not you specifically) want cloud providers to become massive rent seeking institutions, keep optionality in the ecosystem.

For us, it's less that I want to run things on more than one cloud at a time. It's that the next time there's a shuffling of the deck-chairs 5 levels above my pay grade and we end up under someone who says "Oceania Web Services is much better than the Eurasia Cloud Platform! We must move everything at once!" it's not a 3 year migration project (by which time, guess what, Eurasia is mysteriously better than Oceania again).

In my understanding the parent talks about having a system run across several clouds at the same time. Thats sounds like madness indeed

On another hand, I agreee whole-heartedly that having cross-clound compatiable application is actually quite sane.

Even if you're not concerned with real-time redundancy, running across multiple clouds is the only way to ensure that a complex system is truly multi-cloud capable.

If the system is theoretically multi-cloud but only runs on one in practice, it will eventually drift into a state of dependence on that specific environment, even by accident.

Consider yourself lucky if "being better" is the only reason to initiate a multiyear cloud migration project. We are doing one at the moment where everything is going to be objectively worse with the new provider.

I can probably do multi-cloud with Oceania Web Services and Eurasia Cloud Platform, and still end up spending less money *and* having fewer issues, than using this provider.

But your point still stands. Multi-cloud is the way to go.

Ex-Amazon SDE here.

> Then again, we're not servicing any life critical systems.

Reminder: you almost never increase reliability by adding layers of abstraction.

You increase reliability and security by removing complexity/code as much as possible and implementing redundancy in few crucial places.

Some places are mandated by regulators to demonstrate multi-cloud capability as an extension of supplier diversity requirements. It can also provide greater leverage in contract negotiations, and more flexibility to take advantage of promotions and differentiated services if you are fluent in the belt-and-braces compute and networking.

Those caveats in mind, I largely agree with you. Many folks treat these incremental fees, redundancies and inefficiencies as a sacrifice made at the altar of availability without acknowledging that the ensuing complexity creates a risk all its own.

It's a big advantage to be able to move to another cloud, not because reliability of course, but having a lever so good in the negotiation with public cloud vendors will help you a lot.

You're right that it requires a very specific strategy and cost layout to go multi-cloud, and 99% of people don't get it. Just like most people shouldn't use K8s, most people shouldn't go multi-cloud.

If it costs $500K in opex to run in one cloud, expect it to cost $1M for two clouds. It's like having Windows tech support for 200 users, and then asking them to support 200 more users on Macs, and support has never touched a Mac before. Support will be spread thin real fast, and this leads to quality issues and service problems.

There's no magic software which erases all of the hurdles required to double your infrastructure using a completely different system.

Sometimes, some service you want or need is not in the cloud you are in. So you start to move some workload closer to whatever you need to use.. And, surprise, surprise. You just moved multi cloud.

> multi-cloud topic is snake oil, an engineering self-purpose and basically the ORM discussion of the '00 years reloaded.

well it really depends.

guess what with k8s you can do a lot of stuff if you want the most simple high availability:

    - regional clusters/multi-az, that most cloud offers
    - single region/single az clusters, but still a combined load balancer
    - multi cloud single region/single az, i.e. only target a single az 
    - multi cloud multi region/multi az

the thing is for many it might be simple to "use multi cloud single region/single az, i.e. only target a single az"

the biggest problem in these multi cloud setup is mostly not some orchestration that needs to happen on top, there are many tools that can do that. it's mostly how to have a backing store that supports it and how to have a load balancer that might not fail if cloud's go down.

In addition to regulated industries that require this because they are life critical, there are applications with legal requirements to host data in the same country as users and vendor X may not operate in that country, plus military applications where the threat model includes people firing missiles at your data centers and spies and saboteurs infiltrating vendors.

Most use cases for self propelled flight don't require rockets that can get to Mars, either, but we still celebrate their existence on Hacker News.

all healthcare and financial service providers have no choice here.

especially for business continuity, etc audits

Every healthcare and finance service provider I've ever seen is single-cloud. They may talk big about multi-cloud but none of them are actually doing it for their whole stack.

Reply on news.ycombinator.com