Show HN: Build for any cloud with the same code

54 点作者 goncalo-r将近 3 年前

We have been working on Multy, an open-source[1] tool that enables developers to deploy and switch to any cloud - AWS, Azure and GCP for now.We realized that, even when using Terraform, writing infrastructure code is very different for each cloud provider. This means changing clouds or deploying the same infrastructure in multiple clouds requires rewriting the same thing multiple times. And even though most core resources have the same functionality, developers need to learn a new provider and all its nuances when choosing a new cloud. This is why we built Multy.Multy is currently available as a Terraform provider. You can write cloud-agnostic code and then just choose which cloud you want to deploy to. Multy will then call the cloud provider APIs on your behalf. For example, the following Terraform code deploys a virtual network in AWS and can be easily changed to deploy to Azure or GCP:``` resource "multy_virtual_network" "vn" {<pre><code> cloud = "aws" // or azure, or gcp name = "multy_vn" cidr_block = "10.0.0.0/16" location = "eu_west_1"</code></pre> } ```Our goal is to expose any configuration that is common across all clouds, but there’s always specific features that are not available in all of them. For example, if you want a very specific AWS CPU for your Virtual Machine or use a region that is only available in GCP. To enable this, we implemented overrides [2] - a way to configure the underlying infrastructure for cloud-specific purposes. You can also mix other Terraform code that uses the cloud-specific providers with Multy. While this makes you somewhat locked in, having your 80% or 90% of your infrastructure cloud-agnostic is still very powerful.You can see more complex examples in our documentation - <a href="https://docs.multy.dev/examples/" rel="nofollow">https://docs.multy.dev/examples/</a>.We’re still in early days and looking for feedback from other developers on our approach. Let us know what you think![1] <a href="https://github.com/multycloud/multy" rel="nofollow">https://github.com/multycloud/multy</a>[2] <a href="https://docs.multy.dev/overrides" rel="nofollow">https://docs.multy.dev/overrides</a>

9 条评论

joshstrange将近 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 point you are still locking yourself in, just with an extra layer to debug. When I get the time I'm considering switching to just AWS Cloud Formation instead of dealing with a translation layer that translates practically nothing. I mean I know there is some syntactic sugar that I'll miss or have to recreate but it's not like I could pick up my codebase and move to GCP on any reasonable timescale.Couple all that with the fact that using straight VMs on any cloud is one of the more expensive options available to you. As in you're better off in most cases using managed services if you are looking to save money or make life easier. If all you use is EC2/GCP-equivalent then I think in most all cases you'd be better off using a different provider (OVH/Hetzner/etc).

评论 #32387847 未加载

评论 #32386697 未加载

评论 #32387540 未加载

solatic将近 3 年前

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.

latchkey将近 3 年前

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.

评论 #32387378 未加载

txutxu将近 3 年前

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 instance.Looks promising.

评论 #32392689 未加载

tragictrash将近 3 年前

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.

siddontang将近 3 年前

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.

0xbadcafebee将近 3 年前

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.

actionfromafar将近 3 年前

It's nice to see a cross platform library for these proprietary operating systems. (AWS, Azure and GCP.)Reminds me of GNU Libc back in the day before Linux when it ran on Ultrix, BSD etc.

ehutch79将近 3 年前

Don't most cloud providers have some kind of VM/VPS/whatever, that is essentially just a linux instance? It's not hard to just script setup and deployment.Adding layers on top of serverless or whatever just to get back to that point seems dumb.

评论 #32387325 未加载

评论 #32387437 未加载