News for hackers. Stuff that matters.
Re:Visualizing Meltdown on AWS by scurvy on Saturday January 13, 2018 @12:47AM (#16138443)
"Why I like to run my own hardware for $100, Alex"

You can patch various tiers of servers at your own leisure, depending on threat levels and exposure. Measure the impact, capacity plan, etc. Rather than it being forced on you across all tiers because cloud.

Re:Visualizing Meltdown on AWS by amazingman on Saturday January 13, 2018 @02:31AM (#16138640)
You forgot to type 5 or 6 zeros there.
Re:Visualizing Meltdown on AWS by gnosek on Saturday January 13, 2018 @05:28AM (#16139028)
https://www.kimsufi.com/us/en/

Granted, that's the bottom of the barrel (single disk, no IPKVM etc.), but $100 keeps you running for over a year. Better servers are easily available as well, usually a couple of times cheaper than AWS.

Is this a US thing? Based on HN only, I'd never know there's anything between the public cloud and racks of own hardware that you have to wire up and maintain.

I have a bunch of quad core 32 GB machines with dual 480GB SSDs for less than $100/month each (and that's a rather expensive provider with great support, you'll cut the price almost in half with e.g. SoYouStart).

Yes, AWS is convenient, but it's far from the only thing in the world.

Re:Visualizing Meltdown on AWS by user5994461 on Saturday January 13, 2018 @01:33PM (#16140584)
HN has a lot of professionals. They can't run a business on a refurbished server without ECC and without RAID and without dual power supplies.

Saying that they should run on kumsufi is like explaining to a wholesale company that they should use motorbikes instead of trucks, because motorbikes are cheaper.

Re:Visualizing Meltdown on AWS by gnosek on Saturday January 13, 2018 @02:05PM (#16140756)
Of course. I'm not telling anybody to run on kimsufi, like I'm not running kimsufi myself, but on brand-new Supermicro machines that check all your boxes.

Kimsufi is still dedicated hardware (however low-end) that costs 1 figure instead of 5/6. For normal server-grade hardware it's just 5x cheaper than AWS, not 20x.

Re:Visualizing Meltdown on AWS by user5994461 on Saturday January 13, 2018 @02:17PM (#16140834)
Kimsufi and soyoustart are brands of OVH. You don't need to explain again and again that they sell cheaper servers than AWS. Same for super micro. The HN audience know the common suppliers.

Again, you're arguing for motorbikes instead of trucks because they are cheaper. Noone care about that, trucks were not selected based on costs in the first place.

Re:Visualizing Meltdown on AWS by late2part on Saturday January 13, 2018 @01:52PM (#16140691)
AWS Advocates Eventual Consistency, and I believe offers less than 3 nines guaranteed uptime on many products.

We've been taught to build distributed system with unreliable componens and temporaral JIT eventual consistency.

Of course we can run production cloud-scale operations on unreliable systems. And single power supplies without ECC or RAID is pretty low on my list of things that cause outages. Most big hadoop/cassandra shops are running without raid and without redundant power.

Re:Visualizing Meltdown on AWS by user5994461 on Saturday January 13, 2018 @02:27PM (#16140874)
hadoop/cassandra are replicated to multiple nodes by the software. That's a terrible argument for not using any raid in regular setups.
Re:Visualizing Meltdown on AWS by late2part on Saturday January 13, 2018 @04:50PM (#16141617)
I suspect your and my definition of regular setups is different. My regular setups are stateless and automatically installed and configured.
Re:Visualizing Meltdown on AWS by user5994461 on Sunday January 14, 2018 @08:40AM (#16144199)
Lucky you, never having to deal with any database or storage.
Re:Visualizing Meltdown on AWS by amazingman on Monday January 15, 2018 @06:38PM (#16154475)
Yeah, and AWS has a free tier. $0/month is better than $100/month, right?
Re:Visualizing Meltdown on AWS by scurvy on Saturday January 13, 2018 @10:45AM (#16139951)
HN types are enamored with the scale and size that is necessary to run the massive framework for their blogs.
Re:Visualizing Meltdown on AWS by lykr0n on Saturday January 13, 2018 @09:44AM (#16139776)
If you know what you are doing, it is leaps and bounds cheaper to run your own hardware (co-located, rented from soneone else). The only issue is latency on scaling out (hours), but if you are halfway decent with trend lines you can preempt this.
Re:Visualizing Meltdown on AWS by xiaodown on Saturday January 13, 2018 @09:50AM (#16139794)
That's not the only issue; there's also a lot of compliance issues that having a hosting company can take care of. There's whole sections of PCI and HIPPA compliance that you can just write off as "not our problem, talk to AWS".
Re:Visualizing Meltdown on AWS by scurvy on Saturday January 13, 2018 @10:38AM (#16139926)
PCI compliance had little to do with where you're hosted, but how you're hosted and what you do with data.

AWS is not a magical PCI compliance button.

Re:Visualizing Meltdown on AWS by 013a on Saturday January 13, 2018 @01:13PM (#16140485)
Theoretically, it isn't. In actuality, and in our experience, there are a lot of compliance standards where just saying "we're on AWS" gets you 90% of the way toward acceptance. Its mostly buzzword compliance.
Re:Visualizing Meltdown on AWS by scurvy on Sunday January 14, 2018 @10:20AM (#16144574)
That's just not true. Most of PCI compliance is documenting practices and operations. Have you even completed all various levels of compliance? Or have you just done one level?
Re:Visualizing Meltdown on AWS by amazingman on Monday January 15, 2018 @06:28PM (#16154410)
And what if the delta between your upper and lower daily “trend lines” is measured in millions of requests per hour? Per second? We can leave off weekly/seasonal trends for now, and keep it nice and easy for you.

The utter lack of imagination that I see on HN when people are judging others’ technical decisions is kind of hilarious.

Re:Visualizing Meltdown on AWS by scurvy on Tuesday January 16, 2018 @09:46AM (#16158501)
It was a Jeopardy! reference. Sorry if it didn't come through.
Re:Visualizing Meltdown on AWS by stephengillie on Saturday January 13, 2018 @09:56AM (#16139814)
It's very easy for a single admin with a single machine to provide 4 nines to a small group with a small load. But this usually scales exponentially.
Re:Visualizing Meltdown on AWS by scurvy on Saturday January 13, 2018 @10:42AM (#16139940)
Just because you can't do it doesn't make it impossible. A small team of 4-5 good ops people can scale a network of many thousand nodes, petabytes of storage, and terabits of network throughput.

Tech stuff isn't hard. The biggest problem is the lack of capacity planning and project communication in tech today. Nimble startup is a euphemism for pure anarchy and chaos. No one wants to plan anything any more.

Re:Visualizing Meltdown on AWS by user5994461 on Saturday January 13, 2018 @01:47PM (#16140666)
The same infra could be managed by a single guy if it were in the cloud.
Re:Visualizing Meltdown on AWS by scurvy on Sunday January 14, 2018 @10:24AM (#16144592)
No, because that "guy" would want a vacation and would suddenly become the most important person in the company. You're running teams of people, not cogs. Once you realize that, you'll also realize that cloud services are like 5-6x the total cost.

Cloud services are not efficient or cheap, they're convenient for the unprepared and haphazard management style that VC's love.

Re:Visualizing Meltdown on AWS by amazingman on Monday January 15, 2018 @06:35PM (#16154452)
You should review the difference between CapEx and OpEx, and specifically focus on why companies might prefer to pay “5-6x the total cost” when that cost comes in the form of OpEx.

You may still disagree in the end, but you should come to the conclusion that it is not categorically stupid for some companies to choose to pay much more over time so that they can pay a lot less right now.

Re:Visualizing Meltdown on AWS by stephengillie on Monday January 15, 2018 @11:04PM (#16155730)
Only by abstracting away hundreds of teams that manage the actual hardware.