"First remove the closed source vendor lock in from your own codebase before checking for license issues in your neighbor's codebase" Engineerings 5:33
"First remove the closed source vendor lock in from your own codebase before checking for license issues in your neighbor's codebase" Engineerings 5:33
You're viewing a single thread.
Except AWS runs on Linux...
So does the unity engine and that doesn't make it any less closed source.
That's not what I meant by "runs on Linux." I mean the software that makes AWS servers function, behind the scenes, is Linux. You're allowed to install whatever you want on a server if you rent a server from AWS, but the software that allows you to rent a server from them and lets you set up your own server is.... Linux.
AWS servers run on an operating system that is a CentOS/RHEL flavor of Linux that has been heavily modified by Amazon for their use-case.
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.
If AWS decides tomorrow to pull a Unity, can you fork it and keep your business running? Or do you need to rebuild an entire deployment infrastructure?
If your cloud provider decides to screw you you're gonna have to put physical infrastructure together no matter what license their software is distributed under.
Motherfuckers out here think data isn't a physical object and that the cloud is actually a cloud.
No, god damn it, all data is stored in a medium, whether that's a book, a Bluray disc, or a hard drive. It's mediums for storing data. If you destroy the storage medium, the data ceases to exist. Thus, data is a physical object.
Data is reliant upon a physical storage medium, like helium (or other gas/water/pee) is reliant upon a balloon. Pop it, and it’s lost to the ether.
/Star Trek simile
Excellent addition. Star Trek similes are always welcomed.
o7
That is incredibly pedantic.
A balloon is a balloon regardless of whether its inflated or not, but you still need to inflate it in order to serve its purpose - so for all intents and purposes, a balloon needs to be inflated to be, y’know, a balloon. Same goes for data; it needs to be physically stored on something in order for it to be used in the way we commonly imagine people using data, so for all intents and purposes, data is a physical object.
Consider this: if I have a piece of code written out in my head and I didn’t put it down anywhere physically, is that considered data?
And you complained about me being pedantic… lol
Data is not physical; it’s ephemeral. It requires a physical medium in/upon which to be contained.
Edit: and to answer your question: no. What’s in your head would be considered an idea, a thought, or a concept. Perhaps even a consideration, as you literally stated.
suppose you already own the servers, magically or something, could aou set them up to take lour aws workload? no, you have none of the software that aws uses that manages the whole thing. You can host your applications yourself, but you're in for a big rewrite if you do.
Yes. Because I intentionally design systems to avoid vendor lock-in by, at the very least, including a plan to export data and keep IaC in a repo so that it can be used to redeploy at either another vendor or colo-based servers.
Here's some good tools to do so:
- Foreman Self-managed Metal-as-a-Service/VM-as-a-Service orchestrator. It's FOSS.
- Terraform Formerly FOSS, now moving to BSL due to service providers taking advantage of them. IaC tooling that allows one to rapidly deploy and manage infra on multiple platforms.
- Keycloak FOSS IAM platform that's pretty straightforward to use.
- Talos Many choices here but I've used Talos before. It's a FOSS K8S-specific Linux distro that is designed to be platform agnostic and auto-deployed with a simple config.
- Helm K8S deployment manager. Need a DB? You can probably find a chart.
There's a ton of other possibilities but FOSS and source-availabile licensed software makes it pretty straightforward (though still time-consuming as no infra is fully cloud agnostic due to non-standardization between the big three in infra primitives).
so, how many clicks is that?
That wasn't in the initial reqs. And, supposing the hardware was good to go, about the same as AWS.
ETA: The time/click savings is more likely to be in maintenance because using a cloud service is just paying someone else to do that for you.
Running your server on someone else's hardware isn't the same thing as using not using open source?
AWS's servers themselves run on an Amazon-modified flavor of Linux. I'm pretty sure this version already is a fork of CentOS or RHEL.
If you choose to use AWS, you can choose a variety of Linux flavors to run.
If you choose to leave AWS and you have to find a new hosting provider or need to procure hardware to host it yourself, that has nothing to do with the provider being open source or not. Them forking their versions of Linux really only affects Amazon internally, they're not giving their internally used version out to everyone for use. They have Amazon's Linux 2 which they do give away to everyone to use, but why would you use it when there's more open versions of Linux available?
Once again, this seems mostly like people confusing using open source software and using hardware that someone else owns. Open source isn't about who owns the hardware, that's a private property issue. That's more akin to setting up your business on Amazon's lawn and then getting frustrated when Amazon isn't mowing their lawn and your business can't be seen from the road. Honestly, that's what you get for setting up shop on someone else's property where they already have their own shop.
You keep making the assumption that AWS == EC2, meanwhile it is just one of many services AWS provides.
I'm literally not talking about the services they provide, I'm talking about the AWS servers themselves. The physical box that lives at Amazon. To boot up it has to have an operating system. That OS is a flavor of Linux. The number of people who have not understood that in this thread is downright mind boggling.
Who cares what OS the AWS machines are running? I can't touch it, it's completely inaccessible for me and other clients. I can only touch the services which AWS provides. I wouldn't know the difference if it was running windows, since the OS is completely transparent, basically a hidden implementation detail.
Except most people running their services on AWS are not using just the EC2 instances. I would even go as far as saying no one in their sane mind uses AWS just for EC2, at which point you are probably tied to the services you use. If Amazon goes full Unity, and you are lucky it's things that have alternative implementations like S3, if it's something like sagemaker you're fucked.
Y'all are fundamentally talking about different things and are failing to see why they are different.
Vendor lock in from proprietary software is not the same thing as vendor lock in from using vendors hardware.
Both are bad, but they are not the same, and conflating the two is misunderstanding the point. Just like the original meme misunderstood the point.