Skip to main content

Multy vs Terraform

Terraform is the de facto infrastructure as code tool for most teams to deploy their resources. It allows you to use the same interface to deploy resources to most cloud services.

While this has been great for teams looking to deploy infrastructure to multiple clouds, it places all the burden of designing and writing that infrastructure in the development teams. Simple resources are tied to a specific cloud and cannot be reused when changing providers. Multy was born out of this exact problem.

Teams are constantly faced with a tough decision when it comes to infrastructure:

  • Prioritise speed and ease-of-use by leveraging cloud managed services getting locked-in to a particular cloud provider
  • Avoid lock-in by self-hosting open-source alternatives which is time consuming and expensive to run

Why Multy

Multy offers a different approach to this issue by allowing you to use cloud managed services but still have the flexibility needed to move providers if necessary. While Terraform allows you to be multi-cloud, Multy takes it one step further.

Multy creates a higher level of abstraction where resources have cloud-agnostic parameters that don't change when you are moving clouds.

Write Once, Deploy Many


Let's compare the two by looking at a virtual_network resource.

resource "multy_virtual_network" "multy_vn" {
name = "multy-vn"
cidr_block = ""
location = "eu_west_1"
cloud = "aws" # or "azure"

While AWS, Azure and GCP are offering the same service, there are differences and nuances in the way they work that make it difficult to easily maintain multiple configurations. With Multy, to move clouds you only need to change the cloud parameter to change the underlying provider, everything else stays the same.