Live data from Hacker News

Self-Hosting Still Pays

servethehome.com

171–180 of 343 posts

Re: Self-Hosting Still Pays

#171

Even ignoring labor, none of these analyses ever consider BC/DR or backup costs. S3 for backups is the single biggest ease-of-mind feature AWS provides, IMO. I do not want all my data sitting in a single colocation facility without backups. If I run a database on RDS, maybe it costs more than a bare-metal server, but I can replicate the automatic hourly backups to as many regions as I want. Incredible peace of mind o…

Maybe just take a few days and learn how to do backup with a few simple commands?

Fortunately we have tools like borg that is stable and does your backup encrypted easily.

My mind only rests when I have my data encrypted locally before being sent and are put on different providers and regions.

Cost of not trying to learn because clicking seems easy is a cost by itself.

Re: Self-Hosting Still Pays

#172

Good luck hiring the professionals needed to run a bunch of co-located servers in 2020.

Maybe this is my old-school sysadmin showing, but how is managing a rack server more difficult than managing an EC2 instance? The hardware part is not difficult, if you've built a PC you can set up a rack server (it's arguably easier because they're built to assemble without needing tools), and the software is all Linux on both, no? Or do you mean hiring on-site engineers within driving distance of your rack servers…

When you can effectively spawn a new server with a command line you've got saved in your notes... it kinda feels a bit inefficient to be physically building and deploying them yourself.

It's also really pretty amazing to be able to spin up instances or services to test with for however many hours you need and then simply release them again.

Once you've got used to that level of freedom and convenience it's hard to go back, everything just moves faster.

Re: Self-Hosting Still Pays

#173
post #80

If I'm reading the source html pages of "servethehome.com" correctly, it's a Wordpress site and that's what Patrick is basing hosting cost comparisons on. I've mentioned before[0] that AWS too expensive and overkill for Wordpress sites (especially simpler non-ecommerce ones). I don't think this conclusion is controversial. Simpler hosting requirements is why Patrick only has to spend 4 hours of labor in 1 year to upg…

Wordpress hosting is expensive and overkill to do on AWS if you do it traditionalally.

Add simply static or a similar plugin, whip up a script to upload the static HTML to S3, set up Cloudfront with good cache, and you're done. Your site is faster, more secure, cheaper and can easily run on a t3.micro for peanuts.

Only gotcha is comments, but it's a solved problem ( disqus or any of the alternatives) and similar.

Re: Self-Hosting Still Pays

#174
post #138

I have my own 1/2 cab, AS number, ARIN allocated IP4 and IP6 space. It costs about $500/mo. It took maybe 100 hours to set up the basics and $6000 for the way I built the hw (which is similar to servethehome's rack). I run everything on FreeBSD. I get to directly talk BGP and get bandwidth at .12c/gbit. Nothing else can come close to this level of low cost, control, learning, and autonomy.

.12c/gbit?? I need to renegotiate my transit bill...

he.net is .09!

Re: Self-Hosting Still Pays

#175

Earlier quoted context omitted.

I agree that scalability is rarely an appropriate reason to go in on AWS; however, “managed services” is a really good reason. You don’t have to operate your own equivalent services, but rather you pay for Amazon engineers to operate them on your behalf. Of course, there are some people for whom running their own services is the more appropriate scenario, but I think this is not a good default for anything more compl…

It's not that Amazon has worse engineers: They have great engineers. The difference is they are Amazon's engineers, not your engineers. My IT team is not going to break something on the most important day of the month for my business. Sometimes even when I want to do something mundane on the network, it's "eh, let's wait until not (insert key date here), just in case". Amazon does not care what day is important to my…

> You are going to pay IT staff either way, if it's your own hires (or an MSP), or you are paying via AWS fees. If you're going to pay for IT, why wouldn't you pay for IT that takes orders from you and cares about your business?

Because my IT staff budget would go up if they have all of the additional responsibilities that we currently outsource to Amazon by considerably more than what we would save on our AWS bill by doing it in house. This makes sense because Amazon has a lot more customers besides just me paying for their engineers to manage a given service. So I would be paying a premium "for IT that takes orders from me and cares about my business" and that premium is rarely worthwhile. In the worst case, I have an important customer demo and an Amazon outage occurs--I just explain to my customer that we're affected by the same Amazon outage that's affecting all of their other vendors and half of the rest of the Internet and I forward them the Amazon post-mortem. This has never been a problem for me to date, and I doubt there are many people who have lost deals on account of Amazon in excess of their savings for using Amazon (no doubt there are a few companies for whom this doesn't hold and they should seriously consider on prem).

> Similarly, a single patched Exchange server running on a single VM on a VM host with a UPS backup on it is generally speaking, more reliable and has better uptime than Office 365. Hilariously, Office 365 also costs a lot more.

If I had claimed that every managed service was worth its price for every user, then you'd have successfully refuted me. :) No doubt there are some managed services that aren't worth the price, and even an individual managed AWS service probably doesn't justify the cost of integrating with AWS; however, if you're going to be needing analogs for IAM, Lambda, EKS, SQS, CloudWatch, etc, you're probably going to be spending more on balance (and incurring more downtime) by doing it in house (consider also the difficulty in finding engineers with experience in your exact matrix of tech choices versus general AWS experience).

Re: Self-Hosting Still Pays

#176
post #136
post #62

Earlier quoted context omitted.

Sadly, I’ve seen this at more misguided startups. Microservices solve a problem no startup has until they go series B and grow like bananas. When they actually scale.

Sounds like it has nothing to do with microservices and more that they just blew everything up instead of fixing their firebase schema. But hey, sometimes that's way simpler.

Microservices didn't particularly cause technical issues. Just unnecessary operational overhead. While I'd probably go with a monolith if I was building for scratch, in this case we've stuck with ~5 microservices (we did have over 10) as it works well enough.

Firebase is fundamentally limited though. You simply cannot do things like joins and even filtering and updating is very limited compared to a SQL database. Of course you can implement these things in code, and precompute them and store them denormalised. But at that point you're implementing your own database and it's much less work to move the data to a different database platform. We did a gradual migration which made it relatively painless, although it was still a lot of work. And we're able to move much faster on new features now we have the flexibility of a fully-featured database.

Re: Self-Hosting Still Pays

#177
post #60

Earlier quoted context omitted.

Scalability itself isn't the selling point. It's freedom. It's the freedom to get things wrong, iterate and try again. It's the freedom to move resources around. It's the freedom of not having to wait for your procurement process and approval from a purchasing department. It's the freedom of not having to wait for your operations team to plug in and configure bare metal. And all of these freedoms have compounding int…

It sounds to me like you're describing a corporate environment with all the bureaucracy that comes with such an environment. That scenario likely has the traffic and revenue to justify a full AWS build out. I'm talking about new projects at much smaller companies, or much smaller departments within the company that don't yet know if the product they're building is going to even work. Not to mention; I have the same f…

I am confused how DigitalOcean is different than AWS? Why is a $10/mo DO droplet different than a small EC2 instance?

Re: Self-Hosting Still Pays

#178
post #8

I see so often developers state something along the lines of, "We need to go with AWS!" (sometimes substituting AWS with GCP or Azure) and the reason they always give is "scalability". 99% of the time, what they're building not only doesn't need to scale to that degree but they somehow seem to think that it's always inherently cheaper. Meanwhile, when I build something for a client my first go-to is something like Di…

The system I inherited at my current job was built with "scalability" in mind. That meant use of the Firebase databases and splitting everything out into lots of microservices. Ironically this actually caused scaling issues (even with the very small scale we have at the moment) because the lack of query flexibility in the database meant downloading entire collections in order to provide the necessary functionality. W…

firebase is probably the most hyped and overused tech I've seen. I've run into far too many startups that went to firebase because they wanted to scale fast and didn't realize how limited firebase was for queries.

If you're starting a startup, use postgres for your database. it will handle damn near anything and you can spawn off functionality into microservices as they become bottle necks as you scale.

Hell, postgres lets you write database extensions that perform novel behavior. I saw one the other day that automatically syncs data to elastic search. Wouldn't be that hard to envision having writes to certain tables sync to firebase if you need subscriptions on records for certain parts of your app.

Re: Self-Hosting Still Pays

#179
post #95

Earlier quoted context omitted.

I've mentioned this elsewhere but; I'm not arguing co-location over cloud. I'm arguing inexpensive cloud like DigitalOcean, Linode, or LightSail over a complex AWS configuration designed to scale with near infinite flexibility. Why does a product that gets 100 visitors a day need that? $5-10/month serves them just fine.

LightSail isn't any cheaper than the EC2 instance types backing it. Everything else (VPCs, IAM roles, etc) doesn't have a cost associated. What you're missing is that cost/complexity-wise, LightSail and EC2 are equivalent. The only difference between them is your interface to it. LightSail doesn't give you some pretty necessary knobs to kick things into a working state when the EC2 instances are having a burger. In f…

"Linode is frequently the target of massive global DDOS. I remember well a few years ago the Christmas Eve Linode DDOS because I had to work 20 hours that day."

Those sound like some of the weakest reasons. Is your information still upto date? Are they still experiencing major outages?

The truth is it would save you money to use a digitalocean instance over aws, regardless of your edge cases where some network property is not desirable.

How much do you spend a month more to justify working around that weird networking property?

Is it really worth it for everyone else? What is this weird networking issue we need to spend extra to avoid?

Re: Self-Hosting Still Pays

#180
post #145

Earlier quoted context omitted.

The system I inherited at my current job was built with "scalability" in mind. That meant use of the Firebase databases and splitting everything out into lots of microservices. Ironically this actually caused scaling issues (even with the very small scale we have at the moment) because the lack of query flexibility in the database meant downloading entire collections in order to provide the necessary functionality. W…

It's incredible that with the increases in processing power and storage technology, and the continuous performance enhancements of postgres in particular the last years, any "scalable by design" solution of 10 or even 5 years ago can easily be implemented in postgres these days. I guess the 80/20 rule applies more than ever in these cases. I am far from a database expert, but the fact that I have been able to impleme…

[deleted]
Post reply on HN