5 ms·

You could use containerized lambdas. Your application logic would be mostly safe to migrate around as need be. But then again, migrating from one cloud to anot

You could use containerized lambdas. Your application logic would be mostly safe to migrate around as need be. But then again, migrating from one cloud to another is always a heavy lift no matter how it’s constructed.

vidarh 4y ago
Having done zero downtime migration from AWS to Google to managed servers (chasing credits, and then moving to Hetzner when the credits ran out): it's not much heavy lifting if you treat each cloud provider as just providing raw compute and storage resources.
- jamsauceismad 4y ago
  It's because you did the heavy lifting up front with how your application is designed and how your infra is provisioned (I'm guessing everything is terraformed or something?).
  - sleepybrett 4y ago
    Also a great unlock if you do the bulk of your work in kubernetes. Amazon is certainly doing some things in their kube implementation that will make moving suck more (karpenter, some of their other integrations) in an effort to be better and thus sticky... But it's still pretty easy to go from one kube cluster to another.
  - vidarh 4y ago
    Everything in Docker containers + a service discovery layer (Consul on that particular case) will get you most of the way there as long as you don't get seduced into relying on cloud specific services.
    - scarface74 4y ago
      And then you’re managing Consul clusters (been there done that).
      - vidarh 4y ago
        I never found that a problem. Consul was robust when I used it.
croddin 4y ago
With the lambda web adapter[1], you shouldn't need to make any code changes for web projects, just some dockerfile changes which are only used if it is running as a lambda, so the same image should still work on ecs or another cloud. [1]https://github.com/awslabs/aws-lambda-web-adapter https://github.com/awslabs/aws-lambda-web-adapter

5 ms·

You could use containerized lambdas. Your application logic would be mostly safe to migrate around as need be. But then again, migrating from one cloud to anot

by master_crab 4y ago

vidarh 4y ago
Having done zero downtime migration from AWS to Google to managed servers (chasing credits, and then moving to Hetzner when the credits ran out): it's not much heavy lifting if you treat each cloud provider as just providing raw compute and storage resources.
- jamsauceismad 4y ago
  It's because you did the heavy lifting up front with how your application is designed and how your infra is provisioned (I'm guessing everything is terraformed or something?).
  - sleepybrett 4y ago
    Also a great unlock if you do the bulk of your work in kubernetes. Amazon is certainly doing some things in their kube implementation that will make moving suck more (karpenter, some of their other integrations) in an effort to be better and thus sticky... But it's still pretty easy to go from one kube cluster to another.
  - vidarh 4y ago
    Everything in Docker containers + a service discovery layer (Consul on that particular case) will get you most of the way there as long as you don't get seduced into relying on cloud specific services.
    - scarface74 4y ago
      And then you’re managing Consul clusters (been there done that).
      - vidarh 4y ago
        I never found that a problem. Consul was robust when I used it.
croddin 4y ago
With the lambda web adapter[1], you shouldn't need to make any code changes for web projects, just some dockerfile changes which are only used if it is running as a lambda, so the same image should still work on ecs or another cloud. [1]https://github.com/awslabs/aws-lambda-web-adapter https://github.com/awslabs/aws-lambda-web-adapter