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

Show HN: Build for any cloud with the same code

github.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Show HN: Build for any cloud with the same code

#21

Post by 0xbadcafebee »

latchkey wrote: post #17
0xbadcafebee wrote: post #16

Earlier quoted context omitted.

Or at least use CDKTF which allows you to code around problems, rather than bash your head against TF's awfulness. https://www.terraform.io/cdktf

Wow, that's kind of cool. Didn't know about that. It is me, or is it weird that this has a hard constructor dependency on Constructs[1], which is pretty much undocumented? At least in golang, this brings in some other dependencies and golang init() reflect code [2], which then depends on interacting with javascript!? [3]... something smells odd here. [1] https://github.com/aws/constructs-go [2] https://github.com/aws…

"CDKTF uses Typescript types to generate an assembly file that jsii uses to generate the code bindings for the other supported languages."

Yep, sounds like Terraform-level awfulness. Although they actually took the design from AWS CDK, so I guess we can blame AWS for it.

Re: Show HN: Build for any cloud with the same code

#22

Post by latchkey »

NotTameAntelope wrote: post #20
latchkey wrote: post #19

Earlier quoted context omitted.

Correct, I don't like TF, based on some real world experience using it. I also think it is fair to say that my complaint is valid. Luddite? The 20k+ servers that I manage disagree with you. =)

You even admit you haven't used TF in a long time, and when you did use TF it hadn't been 1.0 yet, which means you should fully expect breaking changes to take place. In no way is your complaint valid for a technology that hadn't even been released yet, and you should know that. And a "luddite" is just "a person opposed to new technology or ways of working." How many servers you do or don't manage is totally irreleva…

fool me once, shame on you; fool me twice, shame on me.

Re: Show HN: Build for any cloud with the same code

#23

Post by NotTameAntelope »

latchkey wrote: post #22
NotTameAntelope wrote: post #20

Earlier quoted context omitted.

You even admit you haven't used TF in a long time, and when you did use TF it hadn't been 1.0 yet, which means you should fully expect breaking changes to take place. In no way is your complaint valid for a technology that hadn't even been released yet, and you should know that. And a "luddite" is just "a person opposed to new technology or ways of working." How many servers you do or don't manage is totally irreleva…

fool me once, shame on you; fool me twice, shame on me.

Yes shame on you for not realizing a 0.x versioned technology would make breaking changes on minor version updates.

Given:

1) Terraform uses Semantic Versioning [0]

2) Semantic Versioning specifically states that 0.x APIs are not stable [1]

Therefore:

Your complaint that a 0.x versioned tool wasn't stable is not valid.

Conjecture:

Your complaint exists as an excuse to remain ignorant of a new tool or technology simply because it is new. This makes you a luddite. [2]

[0] https://www.terraform.io/plugin/sdkv2/best-practices/version...

[1] https://semver.org/#spec-item-4

[2] https://www.google.com/search?q=define%3A+luddite

Re: Show HN: Build for any cloud with the same code

#24

Post by latchkey »

NotTameAntelope wrote: post #23
latchkey wrote: post #22

Earlier quoted context omitted.

fool me once, shame on you; fool me twice, shame on me.

Yes shame on you for not realizing a 0.x versioned technology would make breaking changes on minor version updates. Given: 1) Terraform uses Semantic Versioning [0] 2) Semantic Versioning specifically states that 0.x APIs are not stable [1] Therefore: Your complaint that a 0.x versioned tool wasn't stable is not valid. Conjecture: Your complaint exists as an excuse to remain ignorant of a new tool or technology simpl…

Dear anon-fresh-hn-account, it sounds like you enjoy terraform. What's your use case?

Re: Show HN: Build for any cloud with the same code

#25

Post by NotTameAntelope »

latchkey wrote: post #24
NotTameAntelope wrote: post #23

Earlier quoted context omitted.

Yes shame on you for not realizing a 0.x versioned technology would make breaking changes on minor version updates. Given: 1) Terraform uses Semantic Versioning [0] 2) Semantic Versioning specifically states that 0.x APIs are not stable [1] Therefore: Your complaint that a 0.x versioned tool wasn't stable is not valid. Conjecture: Your complaint exists as an excuse to remain ignorant of a new tool or technology simpl…

Dear anon-fresh-hn-account, it sounds like you enjoy terraform. What's your use case?

I don’t like or dislike Terraform, you’re just not making any sense.

Re: Show HN: Build for any cloud with the same code

#26

Post by siddontang »

I like the idea of supporting multi cloud, not cloud vendor lock-in, but I still doubt providing a tool can solve this.

We have been building a DBaaS(database as a service) for many years. Until now, we have only supported AWS and GCP, have not supported Azure. It is really hard to let your product run stably on multi clouds.

For example, not all the cloud vendors provide the same infrastructure at the same time. We wanted our database run on K8s, but several years before, only GCP provided its managed K8s - GKS, so we had to provide our DBaaS on GCP at first. We also wanted to let our customer use PrivateLink to access our service, but GCP had supported too late than AWS, so we had to provide the VPC mechanism for a long time.

Even all the cloud vendors provide the same service, there are still some differences in the details above. E.g, one customer complained us that they met a backup problem on Google Cloud Storage, they found that the speed of our backup was not the same as our product spec statement. Then we found that we only fully tested this feature on AWS S3.

So Now even our DBaaS runs well both on AWS and GCP, we still don’t have the confidence to deploy the service on Azure. We plan to devote a quarter to testing to run DBaaS on Azure in the end of this year.

IMO, I still recommend handling the interfacing with the cloud directly to let us know the clouds better. Of course there are some awesome tools helping us to do some functional encapsulation, hiding the underlying implementation, but we must ensure these tools are easy enough to maintain.

Re: Show HN: Build for any cloud with the same code

#27

Post by booi »

txutxu wrote: post #4

Always preferred direct cloudformation, instead of terraform, and this was one of the main reasons. Does it support load balancers? And... block storage? snapshots? something like IAM roles and policies? I can see how to do it with "general" things, like subnets, instances... but really curious on how it will manage the real and many differences between cloud providers, once you need anything else than launch an inst…

That's strange because terraform supports all of those. A few years ago there would definitely be some edge cases of resources that terraform doesn't cover and it would be awkward to include manual steps (or automated external scripts) but the last few years have been great. Things like IAM roles, policies, EBS/EFS, snapshot control, load balancers (ALB, NLB) have all had good support for a long time.

AWS does add new products which may take some time to be fully supported in terraform but if you've worked with cloudformation, you'll know some stuff takes time to be supported by cloudformation too.

I would say in 95-99% of cases, terraform will do what you need without any customization at all.

Re: Show HN: Build for any cloud with the same code

#28

Post by yunohn »

latchkey wrote: post #13
goncalo-r wrote: post #9

Earlier quoted context omitted.

Terraform is quite generic in its nature. At the end of the day it's just a state management tool. We decided to start there as it's the de facto IaC tool, but we are planning on launching a web portal soon and offer other ways to interact with Multy in the future such as an SDK and a CLI tool.

If TF was generic, your tool wouldn't be needed. My experience with TF is that it is a terrible SMT because they did non-backwards-compatible upgrades to the state file... which made it impossible to redeploy and I had to not only start over with the state file but also recode a bunch of my TF code to support the underlying plugin changes. Of course this was long ago before it was a final 1.0 version so I'm supposed…

> If TF was generic, your tool wouldn't be needed.

This is unclear to me, and seems easily false. The problem lies with cloud provider idiosyncrasies, not the configuration layer.

Re: Show HN: Build for any cloud with the same code

#29

Post by latchkey »

yunohn wrote: post #28
latchkey wrote: post #13

Earlier quoted context omitted.

If TF was generic, your tool wouldn't be needed. My experience with TF is that it is a terrible SMT because they did non-backwards-compatible upgrades to the state file... which made it impossible to redeploy and I had to not only start over with the state file but also recode a bunch of my TF code to support the underlying plugin changes. Of course this was long ago before it was a final 1.0 version so I'm supposed…

> If TF was generic, your tool wouldn't be needed. This is unclear to me, and seems easily false. The problem lies with cloud provider idiosyncrasies, not the configuration layer.

It is a fundamental issue with TF. It wasn't designed to support that. It isn't generic, it is very specific with the providers. Bolting a generic provider running on top of that isn't going to solve the underlying problems with TF/HCL.

Re: Show HN: Build for any cloud with the same code

#30

Post by tragictrash »

This is the story of all time on my experience. I always see someone working on something just like this.

It always creates a new framework with idiosyncratic development practices that require you to lean the underlying systems to utilize it.

Call me a pessimist, but I doubt the utility of a project like this. Don't get me wrong, it's admirable for trying, but when the rubber meets the road, you're going to need someone who has deep knowledge of each of these platforms to run in production.

Why bother with multy? I'll just write my code so it's easily migrateable between cloud providers, and not use multy.

Sorry for the harsh feedback, but I'm not drinking the Kool aid.

Post reply on HN