You're right. There are open source replacements for most AWS services, but that's like saying Wine under Linux is the same as Windows. For the most part, it works well enough to run most application but there are some that just don't work. PostgreSQL vs CockroachDB. Both speak PostgreSQL, but once you start using any advanced functionality you're going to run into issues.
If you're building on AWS S3 heavily, you're going to encounter features that might not be there in the "open source" version, things that behave differently, or just don't work as well. So while it's a nice thought to have, it's the same logic behind internet competition in the US for some areas. You can pick Comcast cable or DSL/WISP. They're the same, right?
Nothing prevents a developer from not adopting a technology, but we both know there are usually business decisions driving it. If you're already using S3 or DynamoDB heavily, you're already trapped. It's a cult. You're free to leave any time, but why not stay here with all your friends? If you leave you would have to spend millions in bandwidth moving your terabytes of data, hundreds of developer hours to update code, and knowledge building around new products.
You can always replace something with something else. But sometimes it's just not practical.
> There are open source replacements for most AWS services, but that's like saying Wine under Linux is the same as Windows.
That kinda feels like moving the goalposts. If the alternatives aren't good enough, perhaps a company that cares about avoiding lock-in should fund them and help them get better. AWS isn't obligated to help competing products work better, or even to open-source the stack that is a big part of their competitive advantage.
If you don't want to get locked into SQS or DynamoDB or whatever, then don't use it. You can build a queue out of kafka or redis or whatever, and a DDB-workalike out of cassandra or something similar.
I'm just not really sure what it is you're objecting to. If someone adopts an AWS hosted service and then later complains that they can't move off of it, that's on them for not thinking it through at adoption time.
The only alternative here that sounds like it would make people happy is if AWS didn't build anything interesting at all, and instead only gave us EC2 on commodity hardware running Xen. If they did that, they'd fail as a business to other companies that actually build things customers want.
You're absolutely right with an API/ABI with the size and complexity of Win32 there is a risk to have compatibility challenges. Just like WSL v1 and gVisor, as re-implementations of Linux syscalls and subsystems.
To me, well designed web services are more intrinsically decoupled compared to general purpose operating system runtimes or SQL implementations.
As for when and why a group of people decide to exit various relationships, I've personally observed that sometimes cost and practicality is not evaluated completely by decision makers [1], despite various clear economic benefits of remaining.
If you're building on AWS S3 heavily, you're going to encounter features that might not be there in the "open source" version, things that behave differently, or just don't work as well. So while it's a nice thought to have, it's the same logic behind internet competition in the US for some areas. You can pick Comcast cable or DSL/WISP. They're the same, right?
Nothing prevents a developer from not adopting a technology, but we both know there are usually business decisions driving it. If you're already using S3 or DynamoDB heavily, you're already trapped. It's a cult. You're free to leave any time, but why not stay here with all your friends? If you leave you would have to spend millions in bandwidth moving your terabytes of data, hundreds of developer hours to update code, and knowledge building around new products.
You can always replace something with something else. But sometimes it's just not practical.