If possible can you suggest me a lof vanilla products. My team is building a platform that allows anyone to spinup instances on any cloud platform. We’re planning to add support for DNS management ( Route53, Google cloud DNS& Azure DNS) and storage buckets

Just what we need, another platform.

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.

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.

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?).

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.

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.

And then you’re managing Consul clusters (been there done that).

I never found that a problem. Consul was robust when I used it.

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

I don't personally feel like Lambdas themselves are the hard lock-in. It's the stuff around them that really gets into your code or forces specific patterns. SQS, SNS, Dynamo, Kinesis, EventBridge, etc.

Which frankly are the essential parts of a robust cloud architecture. Deploying a server is trivial - just dump it on any kind of compute resource. Managing fault-tolerance and monitoring, etc. between those services is the tricky part.

IME, not if you're using Terraform with proper modularization and can stick to the commonly available feature set. Have one layer of modules that describe what you want (e.g. a virtual server, database, monitoring) and behind that a separate layer that implements it (e.g. creates an EC2 instance, an RDS database or a CloudWatch alert).

Terraform is not “cloud agnostic” anymore than using Python with the various cloud providers SDKs.

Each provider within TF is tied tightly with the cloud provider.

Standard Disclaimer: yes I work at AWS and I do IAC with the CloudFormation or TF depends on what the customer wants

That's a nonstarter just because of how you describe the various services at each cloud provider. For instance, Google cloud is big into using "projects" as organizers for resources, where the closest analogue in AWS land is an entirely separate account.

In my opinion, SQS shouldn't be on that list.

You save a lot of time and resources just using SQS instead of setting up your own servers. And the lock-in is not as problematic as Lambdas etc.

It doesn't require much code change to move to an alternative message queue (RabbitMQ etc.), so the lock-in is minimal. In my projects, I just need to change a few lines of configuration code and the actual message processing code should remain the same.

I don't see much difference in vendor lock-in between EKS and Lambda. The abstraction between your Kubernetes application and the underlying platform isn't airtight.

In my experience writing cloud agnostic infra usually ends up more costlier. Not just in monetary terms running the infrastructure, but also in terms of time spent maintaining the infrastructure.

There’s generally very little point using the cloud if you’re not going to use cloud services.

If all you need is machines then there is still a massive benefit in using the cloud. You can spin up 1000 machines tomorrow without having to buy them, wait for getting them (2 months later), rack them, cable them, ....

Especially if you need a couple of racks things get complicated quickly. If you have never racked machines for a week you probably underestimate the amount of time it takes before you can actually run workloads on them.

And if you need a 1000 machines for x years which otherwise you'd put in your own data center you can absolutely go to AWS, GCP, OCI and bid them down against each other.

> If all you need is machines then there is still a massive benefit in using the cloud.

“massive” is an overstatement. “some” would be more accurate. And your example is correct, which is why I said “generally” in my post rather than “always” or “never”. In fact my current project is using AWS in exactly the way you described.

> If you have never racked machines

I have done. Many times. :)

And there are ways you can get machines at short notice without going down the AWS route. In fact it’s actually pretty easy and used to be really common. I used to use all sorts of different VPS and dedicated hosting for personal projects (while managing on prem stuff professionally). These days a lot of those bigger companies are now just wrapped up as part of “cloud services” but there are still some smaller providers out there doing things old school. In fact I have a few GFX cards for machine learning in a London data centre managed by one such independent provider.

> And if you need a 1000 machines for x years which otherwise you'd put in your own data center you can absolutely go to AWS, GCP, OCI and bid them down against each other.

You’re now talking about cost optimisation and commitment-based discounts, which is a whole other tangent.

Anyways, my point wasn’t that the cloud is more or less expensive than on prem. it was that designing your cloud architecture to be cloud agnostic is more expensive and rarely worthwhile compared with making use of the services offered by whichever cloud provider you’re using.