←back to thread

76 points andout_ | 1 comments | | HN request time: 0.386s | source
Show context
wolando ◴[] No.45926074[source]
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?
replies(3): >>45926090 #>>45926717 #>>45927184 #
ericmcer ◴[] No.45926717[source]
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.

replies(1): >>45927061 #
1. andout_ ◴[] No.45927061[source]
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.