Comment by fastball
4 years ago
I think the claim that Amazon is winning through "vendor lock-in" is pretty silly. Honestly anyone who can't quickly migrate the stuff they're hosting on AWS onto one of the many other cloud platforms is pretty bad at DevOps. If you're using K8S/Docker/etc it should be trivial. But even if you're not, the vast majority of AWS offerings were either built to be API-compatible with other existing tools (e.g. postgres-compat Aurora RDS), are literally identical to other services you can self-host (e.g. ElasticSearch) or others have built services compatible with AWS services (e.g. DigitalOcean's "Spaces" aim to be API identical to AWS S3 – you can literally use Amazon's S3 client libs to interact with various S3-compat services from other clouds).
It's not "lock-in", it's providing a great all-in-one solution. You can host everything you want to host on AWS, which has good stability, good latency, etc. People are locked in because the DX around using AWS for everything your platform needs is just better than other platforms / having different services on different cloud providers (at least for many people).
If you're not using any of the AWS services, that might be true but then you're also leaving a lot of potential on the table.
If you're "cloud-agnostic" and could migrate away from AWS in the blink of an eye then you're paying for an overpriced VM offering and should probably migrate to a cheaper hosting provider immediately.
> If you're "cloud-agnostic" and could migrate away from AWS in the blink of an eye then you're paying for an overpriced VM offering and should probably migrate to a cheaper hosting provider immediately.
No this is what everyone suggesting this does not get. The offerings are not equivalent.
There are a baseline of services that the cloud providers offer that can be made functionally-equivalent. It's not just EC2 but more like EC2,S3,Lambda,RDS,DynamoDB,ECS,EKS (plus some others and of course the other cloud's equivalents). The secret sauce is in the APIs and permisioning and all of these available within the same VPC (talking to each other without paying bandwidth costs).
"Cloud-agnostic" has _never_ meant "just VMs". Some of these services are majorly hard to duplicate on your own VMs as well. Feel free to implement "cheap VM hosting + S3" and burn cash on transit costs.
Cheaper hosting providers do not give you this by miles.
> all of these available within the same VPC (talking to each other without paying bandwidth costs).
That's one of the real key issues, I think.
If bandwidth is 10x cheaper, then maybe you decide it's fine if only half your inter-server bandwidth is free.
1 reply →
It’s not super hard to run your own s3 or peer with wasabi and pay flat transit rate (probably like 10x cheaper than your s3 egress)
I buy the main reason being the all-in-one solution; the comprehensiveness is attractive. However, I think you're underplaying the lock-in: migrating clouds is non-trivial - mostly due to stuff that's not running in k8s/docker/etc; stateful apps (Postgres, etc), and or just static data like s3. This takes time, and careful planning and sometimes downtime - and is mostly avoided due to it being hard.
I specifically talked about state and storage.
You're conflating the difficulty of migrating a complex system to anywhere with "vendor lock-in". It would be harder to migrate an Aurora RDS Postgresql instance to an Aurora RDS MySQL instance than it would be to migrate from Aurora RDS (postgres) to a hosted postgres anywhere else.
That to me screams "not vendor lock-in".
Do you know can I migrate my sophisticated security setup easily over? Including users, groups, roles, policies and instance policies.
Everything on AWS is accessible via API, which means you can easily automate the migration process. So do that?
Obviously the more complex a system is the harder it will be to migrate, but that has nothing to do with Amazon trying to "lock you in" and everything to do with it just being a complex system that there is no industry standard solution for.
It appears you are using one definition of lock in while others are using another. What your version of lock in seems to entail is deliberate actions by the hosting provider to force you to stay with their offering. When I (and others it seems) use it, it just means the natural friction that keeps you in the provider. It doesnt have to be a deliberate strategy to be lock in. That doesnt make it any less difficult/painful to migrate.
The lock in is real, but they are also the best cloud option and its not even close in my opinion.
What would you say they lock you into? What is AWS doing specifically that makes it harder to move between providers than if they were not doing that thing?
1) A vast majority of users are relying on managed services to some degree.
2) Permissions as a whole are usually very ingrained into much of what orgs rely on.
2 replies →