[joshstrange]

Has anyone successfully used a tool like this to near-seamlessly switch clouds? I'm not trying to be a debbie downer but having bought into the Serverless Framework for a project I found that a lot of AWS-specific things crawled into the config very quickly despite the selling point of "you can switch clouds easily". The docs themselves break out GCP/AWS ways to define functions for Lambda/Cloud Functions, at that point you are still locking yourself in, just with an extra layer to debug. When I get the time I'm considering switching to just AWS Cloud Formation instead of dealing with a translation layer that translates practically nothing. I mean I know there is some syntactic sugar that I'll miss or have to recreate but it's not like I could pick up my codebase and move to GCP on any reasonable timescale.

Couple all that with the fact that using straight VMs on any cloud is one of the more expensive options available to you. As in you're better off in most cases using managed services if you are looking to save money or make life easier. If all you use is EC2/GCP-equivalent then I think in most all cases you'd be better off using a different provider (OVH/Hetzner/etc).

[spmurrayzzz]

It seems like this tool solves the "happy path" insofar as folks who use a bunch of managed services that share the same API shape between providers. If you just own a bunch of http services in load balancers, I bet this works really well. But for more exotic deployments (e.g. hybrid cloud & on-prem w/ DirectConnect/BGP arcana), this is going to fall short.

That of course is the primary issue with any of these multi-cloud toolchains, its not feasible for them to understand the makeup of every org's cloud infrastructure. The permutations are practically infinite. As such, they have to make make educated guesses to get a pareto distribution of value. The paradox here is that any truly difficult multi-cloud effort is difficult solely because of infrastructure complexity, not because of API deltas between the providers— the existing abstractions don't improve this at all.

In my experience, you're better off owning your own DSL for this sort of thing, but you're going to run into the same issue of impedance mismatch when your infra gets more complex. As an aside, I always push back on the knee jerk reaction that multi-cloud is ever truly necessary (its rarely is, but thats another topic altogether).

[count]

I saw a demo of one years ago that solved this by merely overlaying their own SDN/compute/etc. onto VMs in each of the supporting underlying clouds.

So you didn't even get the 'least common denominator', you got 'tied to one particular startups cloud definition'.

I run away screaming at this stuff, generally.

[goncalo-r]

I don't believe the goal of Serverless Framework is necessarily to tackle vendor lock in, it's more about simplifying and somehow unifying the deployment process. Similarly to Terraform, it ends up being cloud specific in a lot of the details.

I agree that managed services provided by the cloud providers allow you to save money and make life easier. Our main goal is to enable people to use those that are common across clouds without locking themselves in. Of course some features are only available in some clouds, and you'll still have to deal with data fees if you want to move, but having your configuration cloud agnostic saves you a lot of time if you either want to move or want to go multi-cloud.