3 ms·

> As to "cloud agnostic", don't believe this bullshit. > It is the same story as with SQL. Trying to use frameworks to keep your app DBMS-agnostic but then nob

> As to "cloud agnostic", don't believe this bullshit. > It is the same story as with SQL. Trying to use frameworks to keep your app DBMS-agnostic but then nobody ever migrates their apps to another DBMS. I agree, I can't tell you how many hours I've wasted trying to keeps something (theoretically) cloud or DBMS agnostic, how many problems it's caused, and at the end of the day we could never "easily" move to a different cloud or DBMS without large rewrites. I built on top of the Serverless Framework and I am constantly kicking myself for doing so (eventually I'll move off it for my main project). It's the worst of all worlds and in the Serverless Framework docs they even have sections for "GCF" vs "Lambda", if I have to write my functions/declarations differently then why am I using your layer on top? I know you get a few things for "free" with the Serverless Framework but once your project grows you run into all sorts of issues that are a PITA to work around. The truth is I'm not leaving AWS Lamda for GCF or whatever Azure has, I quite enjoy my "walled garden" and using an abstraction layer only means I get the lowest common denominator or a headache when trying to do something that is normally easy if you've fully bought in.

guhidalg 4y ago
But why would you try to build something cloud-agnostic to run on the most cloud-aware tier: serverless? Computers don't come forth from the ether, your code is always running _somewhere_ and serverless means your provider makes a ton of choices for you. The lowest common denominator across clouds is a VM. If you can run your applications and your databases on VMs, you can run them on any cloud AND on-premises. If you can't run CosmosDB or AWS Whatever on a VM, your choice of DBMS/ORM doesn't affect that you're tied to that cloud provider.
- galaxyLogic 4y ago
  I wonder could micro-services be the solution? Run some of your micro-services on AWS and another on Azure etc. A given micro-service then might be highly dependent on AWS but the part of your application that uses those micro-services would not know anything about internals of AWS etc.
  - guhidalg 4y ago
    Perhaps if you're trying to get the best products from each cloud, but I doubt this would be worth it. For each cloud you are going to need to establish: accounts, payment, access control, continuous deployment, geographical locality of their DCs, distributed logging, billing (and watch out for egress costs!), etc... I cannot imagine the added complexity of doing this would overcome the benefits of doing everything with one provider. But hey if your goal is to bill a client as much as possible by claiming that you're using the best products from each cloud, this sounds like a GREAT business idea.
    - galaxyLogic 4y ago
      Maybe not so much to get the best product out of each but to isolate the dependencies behind micro-service interfaces. Make comparisons and if one provider seem to be clearly the cheapest yet good enough then move more services to them. SEE also: https://levelup.gitconnected.com/how-we-reduced-our-annual-server-costs-by-80-from-1m-to-200k-by-moving-away-from-aws-2b98cbd21b46 https://levelup.gitconnected.com/how-we-reduced-our-annual-s...
- emacdona 4y ago
  Agree that lowest common denominator is a VM. But... I'm curious: has anyone here made an attempt to go "cloud-agnostic" by targeting managed kubernetes offerings? (GKE, EKS, AKS). Just curious how much pain I'd be causing myself if I ever attempted it ;-)

guhidalg 4y ago

But why would you try to build something cloud-agnostic to run on the most cloud-aware tier: serverless? Computers don't come forth from the ether, your code is always running _somewhere_ and serverless means your provider makes a ton of choices for you. The lowest common denominator across clouds is a VM. If you can run your applications and your databases on VMs, you can run them on any cloud AND on-premises. If you can't run CosmosDB or AWS Whatever on a VM, your choice of DBMS/ORM doesn't affect that you're tied to that cloud provider.

galaxyLogic 4y ago
I wonder could micro-services be the solution? Run some of your micro-services on AWS and another on Azure etc. A given micro-service then might be highly dependent on AWS but the part of your application that uses those micro-services would not know anything about internals of AWS etc.
- guhidalg 4y ago
  Perhaps if you're trying to get the best products from each cloud, but I doubt this would be worth it. For each cloud you are going to need to establish: accounts, payment, access control, continuous deployment, geographical locality of their DCs, distributed logging, billing (and watch out for egress costs!), etc... I cannot imagine the added complexity of doing this would overcome the benefits of doing everything with one provider. But hey if your goal is to bill a client as much as possible by claiming that you're using the best products from each cloud, this sounds like a GREAT business idea.
  - galaxyLogic 4y ago
    Maybe not so much to get the best product out of each but to isolate the dependencies behind micro-service interfaces. Make comparisons and if one provider seem to be clearly the cheapest yet good enough then move more services to them. SEE also: https://levelup.gitconnected.com/how-we-reduced-our-annual-server-costs-by-80-from-1m-to-200k-by-moving-away-from-aws-2b98cbd21b46 https://levelup.gitconnected.com/how-we-reduced-our-annual-s...
emacdona 4y ago
Agree that lowest common denominator is a VM. But... I'm curious: has anyone here made an attempt to go "cloud-agnostic" by targeting managed kubernetes offerings? (GKE, EKS, AKS). Just curious how much pain I'd be causing myself if I ever attempted it ;-)