Hacker News Reader

Comment by wolando | Hacker News Reader

Part of the selling point of terraform is that I can easily switch clouds if I need to. That's only partially true, most of your terraform would need to change to move from e.g. AWS to GCP, but still, your (hard-fought) experience with terraform on one platform will help when moving to another. If I define my infra the encore way, will I be locked in to one cloud, or can I easily migrate if I need to? Furthermore, I only see Go and Typescript, do you have a roadmap for supporting more languages?

View on HN

Good question! With Encore, your application code is actually more portable than with Terraform because you are defining infrastructure semantically (eg. "I need a Postgres database"), not with cloud-specific config. The same code deploys to AWS, GCP, or even locally with Docker so no Terraform rewrite is needed when switching clouds.

As for the language support; we support Go and TypeScript today. We're focusing on making these rock-solid first, but more languages are on the roadmap. Python is the likely next candidate.

Do you consider supporting rust?

How could it even achieve that? GCP and AWS don’t follow some higher standardized setup. If you use GCP app engine nothing exactly like it exists in AWS, not to mention even similar services like s3 have totally different configs and behaviors.

If I really cared about that I would just use k8s instead of hoping an infra as code tool mapped all these services somehow.

We provide client abstractions for infrastructure primitives (databases, pub/sub, object storage, etc.). Your application code uses these abstractions, and the actual infrastructure configuration is injected at runtime based on the environment.

For example, your code references "a Postgres database" and Encore provisions Cloud SQL on GCP or RDS on AWS, handling the provider-specific config automatically. The cloud-specific details stay out of your application code.

And if you prefer Kubernetes, we can provision and configure GKE or EKS instead of serverless compute. The point is your application code stays the same regardless.

That's the orm argument. "If I need to switch DBs..."

In practice, that is not really viable and should not be a motivating factor when choosing technologies.

Reply on news.ycombinator.com