Welcome • User Guide
ToS • Privacy • Canary
Donate • Bugs • License

©2024 Poal.co

573

Cloud is not right for every workload or company. There is a lot that should be on-prem or coho in a datacenter. You are not always saving money on cloud and this is good proof of that.

Archive: https://archive.today/4quyQ

From the post:

>We finished pulling seven cloud apps, including HEY, out of AWS and onto our own hardware last summer. But it took until the end of that year for all the long-term contract commitments to end, so 2024 has been the first clean year of savings, and we've been pleasantly surprised that they've been even better than originally estimated. For 2024, we've brought the cloud bill down from the original $3.2 million/year run rate to $1.3 million. That's a saving of almost two million dollars per year for our setup! The reason it's more than our original estimate of $7 million over five years is that we got away with putting all the new hardware into our existing data center racks and power limits.

Cloud is not right for every workload or company. There is a lot that should be on-prem or coho in a datacenter. You are not always saving money on cloud and this is good proof of that. Archive: https://archive.today/4quyQ From the post: >>We finished pulling seven cloud apps, including HEY, out of AWS and onto our own hardware last summer. But it took until the end of that year for all the long-term contract commitments to end, so 2024 has been the first clean year of savings, and we've been pleasantly surprised that they've been even better than originally estimated. For 2024, we've brought the cloud bill down from the original $3.2 million/year run rate to $1.3 million. That's a saving of almost two million dollars per year for our setup! The reason it's more than our original estimate of $7 million over five years is that we got away with putting all the new hardware into our existing data center racks and power limits.
[–] • 5 pts

Agreed! I did this myself and using my own hardware is definitely less expensive than big cloud.

Rather than use AWS or Azure for hosting my stuff, I've gone Raspberry Pi. At first it was an experiment. Today, it's no longer an experiment. I have a cluster of Pis using Debian and consumer grade switches. It has over a 99.9% uptime and is very fast because I write my own server code that does not have have the bullshit overhead of commercial applications. I chose to use Apache2 as the web server and Dot Net core in self hosted mode. I use Apache2 as a reverse proxy. It just fucking works! No problems, it's fast and reliable. I can singlehandedly deal with over 39 websites. No issue what so ever.

I use letsencrypt for the certificates. It's fucking awesome!

My biggest problem is Apache2 seems to run one of my server's CPU to 100% once in a while. I deal with this by restarting Apache2 every day at midnight. That seems to do the trick. I've also got a cron job running that checks to see if my servers are up and texts me in the event a site goes down.

The best part is my Raspberry PIs use only 3 watts. Yes, you read that right. Only 3 fucking watts. Each SBC runs about 6 websites. I probably could do more, but decided 6 sites was enough. I actually do have one cloud server because a customer specifically wanted it, and I use a VM. It only costs me $5/month. It uses a Debian image and I manage it just like all my Pis.

Don't let anyone tell you that you can't run your own servers at home, you most certainly can, and it's cheap!

I printed out a 3D SBC rack that keeps all my PIs tidy.

[–] • 2 pts

Have you considered trying out NGINX or HAProxy as an alt to apache? They may not have the issue you are running into with apache and are both just as easy to maintain.

[–] • 1 pt

Yea, I considered NGINX. But Apache is simple enough to use and I understand it. But maybe I'll setup one SBC on NGINX, why not?

Thanks!

[–] • 1 pt

Good Luck. I like nginx for a lot of things and there are tools to make it stupid easy to use as a reverse proxy so if it fixes the issue you are running into maybe it is worth it. Otherwise, why fix what is not broken.

[–] • 2 pts

Monit might help you with that 100% CPU use problem. You can have it mail you at soon as it happens. You can also tell it to restart Apache when the CPU use gets above a certain threshold.

[–] • 2 pts

Apache going to 100%? That's really odd, I've never seen that across the dozen I've maintained over the years. Is there something trying to hit the site hard like one of the many site checkers that run out there, or are you maybe trying to pull a lot of data across a USB connection? There's also that stupid psuedo-swap process that the Pi uses (maybe gone now, don't know) that would tie a core or two up, maybe you're running out of memory and it's trying swap but can't?

[–] • 1 pt

I have had it happen in some cases.. Though, I am talking about a crazy mount of connections and nginx would probably not have those issues. I can't give more details because of reasons.

[–] • 1 pt

The Apache server that has the 100% CPU problem isn't on any of my PIs but on the Debian VM I rent from Lineode. I suspect the configuration may be too limited in memory. I don't really care because even when it runs at 100% CPU, the site still seem responsive enough. My cron job seems to take care of that problem though.

[–] • 1 pt

Yes, could definitely be memory related…or their VM are just poorly optimized and leaky.

[–] • 4 pts

It's CapEx vs OpEx.. this is why cost-benefit analyses should be a required exercise before seeking a cloud solution. There are myriad of other things that should happen as a pre-cursor as well, but I preach this shit ad-nauseum everyday to my leadership and to business owners. First it was all the rage for on-prem, then it's was full cloud, then hybrid, now cloud divestment. The wheel will turn another 180 in 2 years

[–] • 1 pt

Wasn't the cloud about off-site, redundancy, and scalability? Having non-redundant servers in one location is cheaper if you have the place and connections for them.

[–] • 1 pt (edited )

Yes, and then some. NIST 800-145 basically defines cloud as scalable, ubiquitous access to network resources (in addition to the 5 characteristics). That said, cloud typically carries 4 defined (or recognized) deployment models: private, public, hybrid, and community. Technically any deployment model can be on or off-prem which brings us to defining capital expense vs operating expense - do we buy the physical boxes and infrastructure, plus FTE to configure and maintain or do we just 'rent' space and scale as we need. The Total Cost of Ownership (TCO) really needs to be defined to know what is better aligned with the goals of the organization.

That said, if you host everything on-prem, best to have a off-prem cloud backup for BCDR (business continuity/disaster recovery) and if we host everything in an off-prem cloud, best to have a backup in a separate cloud in a different availability zone - TCO can get really tedious really quick.

[–] • 1 pt

Good points about TCO being something a company needs to assess for themselves, rather than "cloud is always cheaper" or "on-site is always cheaper". It's not my field but I'd hope there are approaches that let a company first use the cloud to figure out how much they really need, then later switch to on-premises and not have to reconfigure things (i.e. they can have their machines present the same cloud interface).

[–] • 2 pts

Oh, someone did the math and figured out that paying for hardware once every 5-7 years is cheaper than paying a monthly price?

That's okay, in 15-20 years it'll be back to the cloud if the kikes don't get their war with Iran and the planet is a post nuclear war hellscape dominated by niggers.