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

11–20 of 30 posts

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

#11

Post by goncalo-r »

joshstrange wrote: post #3

Has anyone successfully used a tool like this to near-seamlessly switch clouds? I'm not trying to be a debbie downer but having bought into the Serverless Framework for a project I found that a lot of AWS-specific things crawled into the config very quickly despite the selling point of "you can switch clouds easily". The docs themselves break out GCP/AWS ways to define functions for Lambda/Cloud Functions, at that po…

I don't believe the goal of Serverless Framework is necessarily to tackle vendor lock in, it's more about simplifying and somehow unifying the deployment process. Similarly to Terraform, it ends up being cloud specific in a lot of the details.

I agree that managed services provided by the cloud providers allow you to save money and make life easier. Our main goal is to enable people to use those that are common across clouds without locking themselves in. Of course some features are only available in some clouds, and you'll still have to deal with data fees if you want to move, but having your configuration cloud agnostic saves you a lot of time if you either want to move or want to go multi-cloud.

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

#12

Post by spmurrayzzz »

joshstrange wrote: post #3

Has anyone successfully used a tool like this to near-seamlessly switch clouds? I'm not trying to be a debbie downer but having bought into the Serverless Framework for a project I found that a lot of AWS-specific things crawled into the config very quickly despite the selling point of "you can switch clouds easily". The docs themselves break out GCP/AWS ways to define functions for Lambda/Cloud Functions, at that po…

It seems like this tool solves the "happy path" insofar as folks who use a bunch of managed services that share the same API shape between providers. If you just own a bunch of http services in load balancers, I bet this works really well. But for more exotic deployments (e.g. hybrid cloud & on-prem w/ DirectConnect/BGP arcana), this is going to fall short.

That of course is the primary issue with any of these multi-cloud toolchains, its not feasible for them to understand the makeup of every org's cloud infrastructure. The permutations are practically infinite. As such, they have to make make educated guesses to get a pareto distribution of value. The paradox here is that any truly difficult multi-cloud effort is difficult solely because of infrastructure complexity, not because of API deltas between the providers— the existing abstractions don't improve this at all.

In my experience, you're better off owning your own DSL for this sort of thing, but you're going to run into the same issue of impedance mismatch when your infra gets more complex. As an aside, I always push back on the knee jerk reaction that multi-cloud is ever truly necessary (its rarely is, but thats another topic altogether).

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

#13

Post by latchkey »

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

I personally think the solution here is to not use terraform. You're trying to bolt this onto something that wasn't well designed for this in the first place. It is going to create so many edge cases that it will be extremely hard for anyone to reason about.

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 to give some flex there, but it put me off badly enough that I'd never consider TF a SMT.

At the end of the day, as long as your tool is on top of TF, it will always be a function of the developer to understand all of the idiosyncrasies of not only the different cloud layers, but also the underlying tool. I think you're trying to solve a great problem, but basing it on TF doesn't help.

You asked for feedback... don't use TF.

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

#14

Post by solatic »

I sympathize with what you're trying to do, but I'm not convinced by this approach. You're either fully, 100%, completely radically anti-vendor-lock-in, or you're fooling yourself.

Either you're doing stuff like:

* You're running your own databases. You use Multy to bring up raw virtual machines, you install e.g. PostgreSQL on it, and you do all the DBA work yourself. * You're running your own DNS infrastructure within the VPC, so that you're not reliant on the VPC's provided DNS. * You're running your own network edge. You use Multy to bring up a raw virtual machine with a public IP, you install e.g. Caddy on it, and you set up the proxy yourself.

Or you end up writing code that implicitly takes advantage of stuff like AWS RDS's IAM authentication, or DNS at 10.0.0.2 pointing to i-0123456789abcdef.us-west-2.compute.internal, or AWS Time Sync Service, or using AWS load balancers, with AWS-issued TLS certificates, etc.

The simple truth is, there isn't a startup on the planet that delivers additional value to customers by mucking around with anti-vendor-lock-in measures. Period (and if you really think you have a counter-example, I'm VERY curious to hear about it). And by the time you've grown to the size where cloud vendor lock-in matters (because of cost vs. deploying your own on-premise infrastructure), basically, it's too late, and your migration project is going to be rather expensive. And Multy doesn't help you migrate to on-premise infrastructure, because it only abstracts the various cloud providers! So you're in for a massive migration project either way.

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

#15

Post by 0xbadcafebee »

I like the idea of it, but there are a hundred things that change between different versions of the same provider and resource, and lots of quirks, gotchas, limitations, footguns you don't find until you run that configuration and then try to modify it. It's hard enough making a single cloud provider work reliably.

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

#16

Post by 0xbadcafebee »

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…

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

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

#17

Post by latchkey »

0xbadcafebee wrote: post #16
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…

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/constructs-go/blob/main/constructs/co...

[3] https://github.com/aws/jsii/

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

#18

Post by NotTameAntelope »

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…

This just sounds like you don't like TF, and no matter how well executed this tool would be, you'd always criticize it for using TF.

I wouldn't really call that feedback, just a luddite-esque bias on your part.

I'm pattern matching your "feedback" as "New thing scary, don't use!"

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

#19

Post by latchkey »

NotTameAntelope wrote: post #18
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…

This just sounds like you don't like TF, and no matter how well executed this tool would be, you'd always criticize it for using TF. I wouldn't really call that feedback, just a luddite-esque bias on your part. I'm pattern matching your "feedback" as "New thing scary, don't use!"

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

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

#20

Post by NotTameAntelope »

latchkey wrote: post #19
NotTameAntelope wrote: post #18

Earlier quoted context omitted.

This just sounds like you don't like TF, and no matter how well executed this tool would be, you'd always criticize it for using TF. I wouldn't really call that feedback, just a luddite-esque bias on your part. I'm pattern matching your "feedback" as "New thing scary, don't use!"

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 irrelevant to that. Terraform is new, you dislike it because it's new (my guess), therefore you are a luddite.

Did you think I was claiming you belonged to the group of 19th century English mill workers who destroyed factory machinery to protest those machines taking your job?

Post reply on HN