551–560 of 643 posts
Earlier quoted context omitted.
Sure - but when AWS goes down, Amazon fixes it, even on the weekends. If you self-host, you need to pay a person to be on call to fix it.
AWS doesn't have to pay people (LOTS OF PEOPLE) to keep things running over the weekends? And they aren't...just passing those costs on to their customers?
Earlier quoted context omitted.
Yup, I hope to god we are moving past the age of 'everything's fast if you have enough machines' and 'money is not real' era of software development. I remember the point in my career when I moved from a cranky old .NET company, where we handled millions of users from a single cabinent's worth of beefy servers, to a cloud based shop where we used every cloud buzzword tech under the sun (but mainly everything was cont…
Tangential point but why is it that so often these leaving the cloud posts use the word "beefy" to describe the servers? It's always you don't need cloud because beefy servers handle pretty much any bla bla bla https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... If anyone from oxide computer or similar is reading, maybe you should rebrand to BEEFY server inc...
Earlier quoted context omitted.
Complexity? I've never set up a highly available Postgres and Redis cluster on dedicated hardware, but I can not imagine it's easier than doing it in AWS which is only a few clicks and I don't have to worry about OS upgrades and patches. Or a highly available load balancer with infinite scale.
> I've never set up a highly available Postgres and Redis cluster on dedicated hardware, but I can not imagine it's easier than doing it in AWS which is only a few clicks I haven ever setup a AWS postgres and redis, and know its more then a few clicks. there is simply basic information that you need to link between services, where it does not matter if its cloud or hardware, you still need to do the same steps, be it…
I cannot overstate the performance improvement of deploying onto bare metal. We typically see a doubling of performance, as well as extremely predictable baseline performance. This is down to several things: - Latency - having your own local network, rather than sharing some larger datacenter network fabric, gives around of order of magnitude reduced latency - Caches – right-sizing a deployment for the underlying har…
The AWS documents clarify this. When you get 1 vCPU in a Lambda you're only going to get up to 50% of the cycles. It improves as you move up the RAM:CPU tree but it's never the case that you get 100% of the vCPU cycles.
Earlier quoted context omitted.
> What is old is new again. Over the years I tried occasionally to look into cloud, but it never made sense. A lot of complexity and significantly higher cost, for very low performance and a promise of "scalability". You virtually never need scalability so fast that you don't have time to add another server - and at baremetal costs, you're usually about a year ahead of the curve anyways.
People are usually the biggest cost in any organisation. If you can run all your systems without the sysadmins & netadmins required to keep it all upright (especially at expensive times like weekends or run up to Black Friday/Xmas), you can save yourself a lot more than the extra it'll cost to get a cloud provider to do it all for you.
Earlier quoted context omitted.
I've maxed out lots of CPUs at Hetzner over many years, and across multiple companies, and had clients do the same, so I find your claim to be dubious unless you're talking about shared CPU cloud instances in which case I wouldn't be surprised but also wouldn't consider it unfair. So let me revise that to say I haven't seen any reports I can 1) verify are first hand, and 2) know accurately reflect an actual unfair te…
Maxing out a CPU for a day or a week doesn't count. It has to stay maxed out close to for a month, maybe more. There are no "fair" terminations except without a court order. You will understand when it happens to you. Also, there is no way for you to determine if a report of a a termination is "unfair". In this way, you will continue reveling in your limited worldview. I have seen this multiple times with German prov…
That you're being evasive makes it very much sound like you used them in ways you should have expected would be treated accordingly.
If you've run into this multiple times, it very much sounds like a "you problem".
Earlier quoted context omitted.
Hosting a database is no different than self-hosting any other service. This viewpoint hath what cloud wrought, this atrophying of the most basic operational skills, as if running these magic services are only achievable by the hyperscalers who said they are the only ones capable. The answers to all of your questions are a hard: it depends. What are your engineering objectives? What are your business requirements? Up…
I would argue that correctly tuning a database is significantly more difficult than most services one would self host. But that said, you can afford a lot more hardware if you’re not using RDS, so the tuning doesn’t need to be perfect.
Being a bit obtuse to tune doesn't really justify going all-in on cloud. It's all there in the documentation.
Earlier quoted context omitted.
I meant +1 DevOps engineer dedicated to managing the added operational complexity.
Why would it be +1? The Devops duties that were performed on AWS are no longer being performed... wouldn't it simply shift to the new stack?
I'd guesstimate a 2× increase in their operational complexity. So, if they previously required 0.5 DevOps of a full-timer, they'll now need one more DevOps full-timer just to handle the added complexity.
Does that make sense to you?
Are there decent US based alternatives to Hetzner? I'd like to have my servers located in the US for a variety of reasons, but most of the alternatives I've seen to Hetzner seem to be pretty fly-by-night shops.