3 ms·
> Even with the discounts, savings plans, multi-year commit discounts, etc., the cloud costs are absolutely absurd if you are running stable applications where
by ary 4y ago
> Even with the discounts, savings plans, multi-year commit discounts, etc., the cloud costs are absolutely absurd if you are running stable applications where you understand the future growth, use, and demand.
This is true, but it doesn't preclude use of the cloud.
The core of the cost issue is, in my view, that software is still designed to run in a datacenter: always on, all code in a single process (yes, this includes microservices), expected to never stop mid-execution. That made sense when you owned the hardware and needed to fully utilize it for the duration of its life. This prevents the best cost-saving measure in the cloud: turning it all off.
People can complain all they want about how the cloud providers operate, but there are ways to utilize cloud infrastructure without breaking the bank. Software development practices have to change, and in the meantime the cloud platform providers are going to make a pile of money as companies shift legacy software to the cloud without the needed re-architecture. We need frameworks and other technologies that, similar to the abstractions we now have for memory management, multi-threading, asynchronous I/O, etc. relieve the burden of reasoning around distributed, disjoint processes from the developer. Then we can finally realize the ideal of "only pay for what you need".
- EVa5I7bHFq9mnYK 4y ago>> but there are ways to utilize cloud infrastructure without breaking the bank. You seemingly refer to a discounted mode of execution in AWS where your servers can be pulled off at any moment and there is no uptime guarantee. That only works because few use this mode. If everyone starts using it, the discount will disappear.
- cassianoleal 4y agoI suspect they were mainly talking about "serverless" (Lambda, Cloud Run, etc) and managed services vs. running your own compute in the cloud. Whether it can be made cost-effective in practice or not, I don't know - I haven't made the calculations. Just saying that's how I read it.
- 8organicbits 4y agoI haven't see that work out in practice, I've suspected that's mostly marketing fluff at this point. Anyone have counter examples? We considered autoscaling web backends once. You've got to worry about capacity issues. You don't want a load spike only to discover EC2 has run out of the instance type you use. I've seen that issue 3-4 times in AWS now and it's painful when it causes downtime. Your app needs to have spikey load for the pricing to work, for us, even a strong day/night cycle didn't give enough "off time" to cover the higher hourly prices. Cloud vendors give steep discounts for always on usage. Your load also can't be too spikey, as spinning nodes up and down takes time. Making nodes start quickly can be a dedicated project. I think we also looked into moving CI/CD servers to on demand, but some engineers worked too late into the night and others were up early. IIRC the "off period" was long enough to provide some cost savings, but not high enough to justify engineering cost. Something like Lambda doing a "scale to zero" with a generous free tier looks cheap, but if you ever need to scale up you'll find it's quite expensive and your stuck with a weird architecture that's hard to move to something traditional. It is cool when an app fits the Lambda free tier, but that's not a good model for companies paying very large cloud bills. The problem is that someone needs to do capacity planning, someone needs to buy servers. AWS has to pay the cost of an unutilized server by... keeping the hourly cost of on demand servers/cloud functions high.
- trasz3 4y ago>all code in a single process Can you give some example of that being the case?
- deleted 4y ago[deleted]
- dijit 4y ago> This prevents the best cost-saving measure in the cloud: turning it all off. However, the cost calculation is weird when you factor that 2 hours of cloud "on" can often pay for an entire day of "on" for a normal server. All else being equal, which I'm aware is a contentious/controversial notion in of itself, even if I personally believe the colo costs for headcount are often greatly overestimated.
- FpUser 4y agoNice try. ">People can complain all they want about how the cloud providers operate, but there are ways to utilize cloud infrastructure without breaking the bank" Alternatively do what I do (example of particular product I developed and nor run for a client): Single exe in C++ talking to a local Postgresql database. Combo is capable of processing thousands of requests per second sustainably without breaking sweat (this will cover business needs for a next 20 years). Also standby always on server with replication. Daily backup to on premises backup server. Hardware for production and standby is dedicated 16 Core AMD with 128GB RAM and 2x4TB SSD. Each rented from Hetzner at about $100 each. Fronted by Clouflare, not sure about the price as Client pays it. All deployment / management / maintenance / backup / Point In Time Recovery is done by couple of scripts. Reinstalling whole thing on a totally new server takes running single script for about few minutes (at some point will take longer as the size of the database grows but would still be very manageable). The cost on Azure for the equivalent processing power and features accordingly to their calculator is 10 times more.
- datadeft 4y agoThis is great. Well most companies I migrate to the cloud are not running a single workload that fits on a single server. Most companies that save a lot by moving to the cloud are the ones which have several workloads, multiple products, teams, and verticals. They got security requirements, compliance, logging requirements to name a few. So yeah, if you only consider a most basic business that has a single website with a single use case and non of the above then Hetzner is a great option.
- FpUser 4y agoThis is why there are containers and you can rent multiple servers as well if there is a need. Security requirements have nothing to do with being on the cloud. You just basically have to encrypt data at rest and satisfy couple of other things to get your SOCS2 label. Did it, no sweat.