The vendor lock in from AWS doesn’t come from just using EC2 servers. EC2 is just linux servers, like you say. You could run them anywhere. In fact, if you’re just running AWS EC2 servers without leveraging their other features, particularly auto-scaling, you’re probably just setting money on fire. Everything EC2 offers can be done much cheaper at a different host.
The AWS lock-in comes when you expand to their other services. Route 53 DNS, Relational Database Service, Simple Email Service, etc etc. AWS offers a ton of different services that are quite useful, and they add new ones all the time. And if your company uses a bunch of them, and then realizes they need to leave AWS, doing so is incredibly painful. Which is the point.
If you hard code their services into your product, sure. But you should be abstracting away from that. Then it’s just writing new plugins instead of redesigning everything.
Abstracting away is costly. You can target only the lowest common denominator. The abstractions are going to leak. It’s like the criticism of ORMs, only worse since SQL is at least standardized.
Vendor lock-in from a service provider is different from vendor lock-in from using proprietary software.
If you’re dumb enough to not host your shit locally and instead rely on Amazon, that’s literally your own shortsightedness that led to vendor lock in.
The first mistake anyone made was thinking putting their whole business on some other businesses private property was a good idea. Pro-tip: it’s not.
In other words, I already agree with you, but I think vendor lock-in for services is a vaslty different issue than vendor lock-in for proprietary software.
My point is that, if someone really leverages the power of AWS, it is entwined into their software stack to such an extent that it is not just a service anymore. It’s a platform. It’s the glue that keeps everything together. The lines between service and proprietary software blur real quick. It’s one of the reasons for the AGPL.
Everything in development involves risk, and products will move real slow if you don’t depend on someone for some services. But developers aren’t very good at risk management, not being reliant on a single service to butter your bread. It is very quick to bring a minimum value product to market on AWS, but the followup to that MVP needs to be moving to a more sustainable, less risky infrastructure.
All right, I agree with that take. However, I would also argue that those are choice you can make when using AWS, and while Amazon surely pushes those solutions through ads and whatnot, it’s still a choice that people can make. Yes, after they’ve made that choice, they’re fucked out of luck if they want to switch to a different service, but that’s why (in my opinion) “the cloud” was always a lie that was meant to benefit large corporations. It reduced IT overhead for small companies, but it did it, like you point out, at the expense of getting locked into the vendor-environment.
If they can’t see that in the future this will cause lock-in… once again, that’s their own shortsightedness and inability to consider the implications of using exclusively AWS servers and services.
The vendor lock in from AWS doesn’t come from just using EC2 servers. EC2 is just linux servers, like you say. You could run them anywhere. In fact, if you’re just running AWS EC2 servers without leveraging their other features, particularly auto-scaling, you’re probably just setting money on fire. Everything EC2 offers can be done much cheaper at a different host.
The AWS lock-in comes when you expand to their other services. Route 53 DNS, Relational Database Service, Simple Email Service, etc etc. AWS offers a ton of different services that are quite useful, and they add new ones all the time. And if your company uses a bunch of them, and then realizes they need to leave AWS, doing so is incredibly painful. Which is the point.
If you hard code their services into your product, sure. But you should be abstracting away from that. Then it’s just writing new plugins instead of redesigning everything.
Abstracting away is costly. You can target only the lowest common denominator. The abstractions are going to leak. It’s like the criticism of ORMs, only worse since SQL is at least standardized.
Vendor lock-in from a service provider is different from vendor lock-in from using proprietary software.
If you’re dumb enough to not host your shit locally and instead rely on Amazon, that’s literally your own shortsightedness that led to vendor lock in.
The first mistake anyone made was thinking putting their whole business on some other businesses private property was a good idea. Pro-tip: it’s not.
In other words, I already agree with you, but I think vendor lock-in for services is a vaslty different issue than vendor lock-in for proprietary software.
My point is that, if someone really leverages the power of AWS, it is entwined into their software stack to such an extent that it is not just a service anymore. It’s a platform. It’s the glue that keeps everything together. The lines between service and proprietary software blur real quick. It’s one of the reasons for the AGPL.
Everything in development involves risk, and products will move real slow if you don’t depend on someone for some services. But developers aren’t very good at risk management, not being reliant on a single service to butter your bread. It is very quick to bring a minimum value product to market on AWS, but the followup to that MVP needs to be moving to a more sustainable, less risky infrastructure.
All right, I agree with that take. However, I would also argue that those are choice you can make when using AWS, and while Amazon surely pushes those solutions through ads and whatnot, it’s still a choice that people can make. Yes, after they’ve made that choice, they’re fucked out of luck if they want to switch to a different service, but that’s why (in my opinion) “the cloud” was always a lie that was meant to benefit large corporations. It reduced IT overhead for small companies, but it did it, like you point out, at the expense of getting locked into the vendor-environment.
If they can’t see that in the future this will cause lock-in… once again, that’s their own shortsightedness and inability to consider the implications of using exclusively AWS servers and services.