Live data from Hacker News

AWS hearts multi-cloud? It's gonna happen

cloudirregular.substack.com

1–10 of 38 posts

Re: AWS hearts multi-cloud? It's gonna happen

#2
Sounds about right. We have 95% of our infra on AWS but then early this year one team needed something specific from GCP and started using that. A few months ago, a client insisted on having their services delivered from Azure as they have a lot of other related services already tied into Azure. 95% on AWS and the other two add up to just 5% - but, hey, multi-cloud!

Re: AWS hearts multi-cloud? It's gonna happen

#3
I have no faith in AWS executing on this successfully. I'd imagine an offering like the suggested one would have some kind of: a) UI to inspect the state of other clouds, b) provisioning capability that allows creation of resources in other clouds.

On the UI front:

- AWS UI toolkit has aged by this point and each day it feels more dated

- CloudFormation, as their main cloud management UI is particularly bad (e.g. limited info on what caused a problem, not displaying ARNs of resources belonging to a stack systematically etc.)

On the provisioning front:

- Terraform and Pulumi are so much better than anything AWS offers, and that says something because even these tools are not great.

Re: AWS hearts multi-cloud? It's gonna happen

#6
This article is not far off in its prediction that AWS would support multi-cloud natively eventually if that's what the market demands (See also: AWS Marketplace). We are very early in our journey and are multi-cloud already and because we're bootstrapped, cost ultimately decides what we use. And no, I don't mean multi-cloud in a way Netflix does it, but in a way where different parts of our system are hosted wholly by different cloud providers. So, in a sense, everything supports multi-cloud already anyways?

> QLDB is a recent entry to the canon. It’s easy to spot these "AWS-native" services because they’re often dogfooded by Amazon retail.

Well, in some cases, it is dog-fooded by AWS themselves. In QLDB's case, the underlying tech was built for EC2 [0] whilst Kinesis Data Streams was built by the Billing team at AWS [1].

[0] https://twitter.com/colmmacc/status/1067832198059970561

[1] https://gigaom.com/2014/03/20/why-amazon-built-its-data-stre...

Re: AWS hearts multi-cloud? It's gonna happen

#7
post #3

I have no faith in AWS executing on this successfully. I'd imagine an offering like the suggested one would have some kind of: a) UI to inspect the state of other clouds, b) provisioning capability that allows creation of resources in other clouds. On the UI front: - AWS UI toolkit has aged by this point and each day it feels more dated - CloudFormation, as their main cloud management UI is particularly bad (e.g. lim…

I agree with you on Terraform and Pulumi (I'm especially excited about the latter, due to extra benefits over Terraform). However, I think that you are missing the main point / theme of the post - it is not specifically about AWS' approach to multi-cloud, but rather about general dynamics of the multi-cloud trend.

Re: AWS hearts multi-cloud? It's gonna happen

#8

This article is not far off in its prediction that AWS would support multi-cloud natively eventually if that's what the market demands (See also: AWS Marketplace). We are very early in our journey and are multi-cloud already and because we're bootstrapped, cost ultimately decides what we use. And no, I don't mean multi-cloud in a way Netflix does it, but in a way where different parts of our system are hosted wholly…

How do you keep the costs down with egress pricing? If the parts of your applications are distributed through cloud providers you all the time are exporting data to egress. Thats not a cheap concept or did you build your software with this in mind?

Re: AWS hearts multi-cloud? It's gonna happen

#10
post #8

This article is not far off in its prediction that AWS would support multi-cloud natively eventually if that's what the market demands (See also: AWS Marketplace). We are very early in our journey and are multi-cloud already and because we're bootstrapped, cost ultimately decides what we use. And no, I don't mean multi-cloud in a way Netflix does it, but in a way where different parts of our system are hosted wholly…

How do you keep the costs down with egress pricing? If the parts of your applications are distributed through cloud providers you all the time are exporting data to egress. Thats not a cheap concept or did you build your software with this in mind?

> How do you keep the costs down with egress pricing?

The AWS components we use are mostly ingress heavy. Egress heavy components are on Cloudflare, Scaleway, and Digital Ocean.

> ...did you build your software with this in mind?

Yep, we designed the system keeping egress costs in-mind, and that meant some of things were a bit more time-consuming (build vs buy) than they normally would have been.

That said, we aren't what you'd call an uber sophisticated upstart using cutting edge tech. Right now, whatever systems we have are all mostly boringly simple and probably won't scale.

Post reply on HN