Show HN: Build for any cloud with the same code

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" {

  cloud      = "aws" // or azure, or gcp

  name       = "multy_vn"
  cidr_block = "10.0.0.0/16"
  location   = "eu_west_1"

} ```

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 - https://docs.multy.dev/examples/.

We’re still in early days and looking for feedback from other developers on our approach. Let us know what you think!

[1] https://github.com/multycloud/multy

[2] https://docs.multy.dev/overrides

Show HN: Build for any cloud with the same code
github.com

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

I saw a demo of one years ago that solved this by merely overlaying their own SDN/compute/etc. onto VMs in each of the supporting underlying clouds.

So you didn't even get the 'least common denominator', you got 'tied to one particular startups cloud definition'.

I run away screaming at this stuff, generally.

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.

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.