Comment by JackSlateur 10 months ago
I've built many projects where "the cloud" is less expensive than the alternatives
The last big one: replacing a backbone country-wide network in France with AWS
It is far less expensive due to the low bandwidth requirements (and also the ability to go full managed services)
Competition?
I've never had AWS "increase the price." Is there some reason to suspect this is a thing to actually worry about?
New public IP charges and Kubernetes base pricing both doubled my bill.
Spot pricing is kind of a black box, and it also makes no sense.
Price is supposed to cut in half every 3-4 years, if it isn't it is largely because cloud vendors can't bear to take less and hope there really is that much more volume of half as valuable computing to do.
The things they sell as an average CPU performance, etc are basically the average when their cloud began.
> Price is supposed to cut in half every 3-4 years
Citation needed
> if it isn't it is largely because cloud vendors can't bear to take less
Even if we choose to accept your original premise, I think anti-competitive behaviour is much more likely than "can't bear to take less".
> if it isn't it is largely because cloud vendors can't bear to take less
Cloud vendors have to buy products themselves. If their prices aren't changing then we have a market problem that extends beyond AWS.
This is probably why Graviton exists and provides cheaper VMs and Lambdas running on it.
> as an average CPU performance
CPU performance, in the cloud, is effectively free. You can overcommit and time share the CPU.
What you're paying for is memory.
Nothing, and they do that regurarly
What stops dark fibers or hardware providers from "increasing the price" ? Nothing, and they do that too
So you're proving my point. The tool cannot tell you the single most important factor in pricing.
You moved the goalpost from "cloud is definitely more expensive" to "well it isn't but maybe it will be for you someday" and alluding to vendor lock-in.
Vendor lock-in is a concern with cloud platforms but doesn't relate to the app in the submission.
Haa, yes, the scary "vendor lock-in" !
I challenge you : give me a single product that cannot be moved away, given some (cost or time).
At the same time, I again challenge you : give me a single product that you can move between providers with no cost nor time.
To that last one, you can actually find stuff. For instance, you could setup your nginx in instances, without any kind of interactions with the hosting provider. In which case, you limit yourself with what everybody can do, leaving all opportunities to only use the base minimal.
But wait .. are you not locked-in with nginx (or to use a better example: with redis) ?
Vendor lock-in is a scam to increase your bills. Because, in itself, everything is vendor locking. And it does not matter. Think your architecture, design your code, and act when necessary.
I don't think you've ever been through the pain of moving a big, fully integrated, multiple ETL pipeline data warehouse built on something like Redshift. Vendor lock in is more about inertia and less about there not being an alternative. Some things are just really, really difficult to move and ridiculously impactful to change.
You seem to be trying to reduce the vendor-lockin issue to a binary "locked" or "not locked," but Idon't think that's a productive or realistic way to think about it. It's really more of a spectrum, and I prefer to think about it as "options" rather than "are we locked." You definitely have a lot more options if you go with Nginx and the project turns evil than you would if you went with some proprietary offering.
You take the term "lock-in" far too seriously.
Yes, one can migrate their entire CI/CD ecosystem, countless IAM policies across multiple AWS accounts in an organization, their lambdas, databases and S3 buckets over to Azure given enough time and money.
The thing is that most everything in the cloud is billed on subscription, and many core components of networked services need not be (except support). Open file server, self-hosted IAM and standards-based execution stacks. Don't like hosting your nginx on Vendor-A? Move it to Vendor-B.
Yes, the tradeoffs are costs. No, vendor "lock-in" is not the only component one should measure when deciding an architecture. Yes, "lock-in" can occur with on-prem software, and hardware, as well.
Yes, it's real and worthy of concern when a vendor knows they can squeeze you because you have no other choice and the level of effort to migrate is too high.
It is always more expensive. I haven’t moved any goalposts. What I am trying to show is that you don’t need a tool - indeed you don’t need to look at a single price of anything - to know why. It can be both more expensive and a better value though! If you can’t recruit people or what you do is boring or if you want to operate a business that loses money in the long run: those are some common reasons it can look cheaper when it’s not.
> It can be both more expensive and a better value though!
No, it can't be. Stop with the pseudo intellectual linkedin lingo please.
RDS is an example of something that is more expensive but can be better value - because a lot of the managed service stuff saves the time of those looking after it.
15 years ago I worked an infrastructure department with 50+ employees - these days a lot of that work that we used to do back then is taken care of by AWS.
Scaling the infra to meet peak capacity (which might be two days in a year) because you can only run on hardware you have, having data centres and data centre engineers, are all costs that go away with cloud, even though you are paying more for the compute you do use.
What stops AWS from "increasing the price" until it is very close to what you were paying before, if not more?