[dinedal]

> if your service succeeds, you will definitely want to move some components out of aws, but not all of it. aws can always remain the control plane.

Do you factor in the costs of dev time in a cross cloud environment at all? Nevermind all the AWS specific tooling and code you write, which needs to be thrown away and re-done to accomplish this?

Don't get me wrong, I love AWS when I'm not paying the bill, it makes my job of shipping features quickly so much easier. It's good and it works well. But it's a little crazy to think it's "cheap" and to ignore the costs of vendor lock in.

[count]

Do you factor programming language and library and operating system and cpu architecture into your vendor locking and specific tooling you need to write?

[nathants]

vendor lockin is fine. it’s like having a great employee, but not leveraging them fully because bus factor and cogs. you should be sad if a great employee leaves, or your vendor shuts down. choose both carefully, and trust them.

my only experience expanding out of aws is to cloudflare for egress. i’m sure it can be rough, but so can anything solved with dev time.

expanding out of aws with individual tightly scoped components should be easier than general cloud migration. just bandwidth egress. just cheaper cpus for background processing. just whatever.

keep the complicated stuff on main cloud where it belongs.