Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS hearts multi-cloud? It's gonna happen

cloudirregular.substack.com

Post reply on HN
Print view View original

31–38 of 38 posts

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

#31

Post by chucky_z »

ablekh wrote: post #14
chucky_z wrote: post #12

Earlier quoted context omitted.

Check out Terraform CDK for a thing that is native to TF, allows real code, and is progressing real fast

Thank you, will keep it in mind. However, Terraform CDK is far from being production-ready at the present time. Moreover, I would venture to guess that it will trail Pulumi in terms of both features and maturity (due to Pulumi team's first mover advantage as well as singular focus on their product, unlike HashiCorp's broad portfolio of products).

I’m a bit confused here. Isn’t Pulumis big claim that it’s compatible with Terraform providers?? Why would Terraform trail that?

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

#32

Post by Saar1991 »

I believe theres still a whole bunch of useful "multicloud" products out there. For instance if you have services in different clouds that talk to each other, having a performance monitoring software that gets data from both and stitches it together is useful.

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

#33

Post by utahcon »

AWS has been very chummy with HashiCorp and Terraform in the last few years, going so far as to announce a Landing Zone collaboration with them

https://www.hashicorp.com/resources/aws-terraform-landing-zo...

and of course the https://github.com/hashicorp/terraform-cdk

I am not sure what I would think of an offering from one cloud provider to support another cloud provider, just seems shady as hell. I could see AWS spinning out an MSP that would handle multi-cloud stuff, because AWS MSP would be "cloud experts", but that might be a stretch too, TBH.

I really see them taking Terraform, and the CDK, and pushing that as their multi-cloud if they were to really lean into that, but there is little to no reward (as I see it) for them doing such a thing. It would just be another tool that will gather dust in a few months while they venture off to exploit another Open Source project in their MSP Cloud providings

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

#34

Post by Proven »

Before he said no one needed multicloud, now the prediction is it will happen because it's necessary.

Well what is the value of that? Last year I knew it would happen because I started hearing first hand from people who were increasingly using multicloud.

One frequent scenario is when companies hire new staff used to one cloud and has existing apps in another. If the app can run anywhere it will likely run where the staff can deploy and manage it easier and cheaper.

Multicloud vendors are needed because there's value in being able to abstract certain functionality or parts of the stack across hyperscalers.

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

#35

Post by ctvo »

ignoramous wrote: post #10
tpetry wrote: post #8

Earlier quoted context omitted.

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…

> 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.

You acknowledge here that the systems you have may not scale. I assume you're still trying to find market fit, and may end up heavily augmenting or redesigning these systems when you do. With that said, why did you prioritize spending your limited resources solving for multi-cloud?

I'm curious if the cost savings of optimizing cross clouds was worthwhile vs. the engineering effort / constraints you introduced into your systems at your scale.

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

#36

Post by ablekh »

chucky_z wrote: post #31
ablekh wrote: post #14

Earlier quoted context omitted.

Thank you, will keep it in mind. However, Terraform CDK is far from being production-ready at the present time. Moreover, I would venture to guess that it will trail Pulumi in terms of both features and maturity (due to Pulumi team's first mover advantage as well as singular focus on their product, unlike HashiCorp's broad portfolio of products).

I’m a bit confused here. Isn’t Pulumis big claim that it’s compatible with Terraform providers?? Why would Terraform trail that?

Yes, Pulumi is compatible with Terraform providers. However, it is a declarative backend compatibility. In terms of imperative frontend, as I said, Pulumi team has both first mover advantage as well as singular focus on their product, unlike HashiCorp with its broad portfolio of products, where Terraform CDK is just one of them (hence, lack of the laser focus).

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

#37

Post by oblio »

_vufv wrote: 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…

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

They're rewriting the console: https://abduzeedo.com/amazon-web-services-design-system

At least a few of their services have already been updated.

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

#38

Post by ignoramous »

ctvo wrote: post #35
ignoramous wrote: post #10

Earlier quoted context omitted.

> 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…

> 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. You acknowledge here that the systems you have may not scale. I assume you're still trying to find market fit, and may end up heavily augmenting or redesigning these systems when you do. With that said, why did you prioritize spendin…

> With that said, why did you prioritize spending your limited resources solving for multi-cloud?

We keep asking ourselves the same too. We initially wandered down the "mutli-cloud" path because it made a lot of sense in terms of cost (like somewhere in the region of 10x lower costs)... but as we chipped away at code, it became quite obvious that the inherent complexities could have been avoided especially since we're so early and barely have a user-base.

> I'm curious if the cost savings of optimizing cross clouds was worthwhile vs. the engineering effort / constraints you introduced into your systems at your scale.

The uber low-cost setup allowed us to offer our services for free to gauge overall interest (given we're a consumer product). My assumption is that free customers are free publicity (in that they help spread the word) and that around 1% would convert to paying customers eventually.

We also biased towards "serverless" offerings to avoid DevOps and SRE, and that has worked quite well: In the three months our alpha has been been live taking ~30M requests a month (ignoring the occasional DDoS), we haven't had a single outage or even bothered to look at the error logs (there aren't any errors).

So to answer your question, yes I believe it was worthwhile since the cost difference is 10x and we were able to offer a free-tier because of that (we're not an enterprise business). Obviously, it sucks that engineering time had to be sacrificed for it, but hey, no pain no gain.

Post reply on HN