Live data from Hacker News

Open Guide to Amazon Web Services

github.com

101–110 of 133 posts

Re: Open Guide to Amazon Web Services

#101
post #80

I converted to pdf using Typora[1]. https://github.com/nodesocket/og-aws-pdf/raw/master/the-open... [1] https://www.typora.io/

Let us know if you find the PDF helpful? We could post one on the GitHub repo too — though it's so full of links I'm not sure how useful it is.

I think the PDF is a useful option, use case being offline reading.

Re: Open Guide to Amazon Web Services

#102
post #29

I still don't get why Opsworks is not getting more love? I guess people don't like Chef? Opsworks has enabled hassle free deployments for us over the past three years or so at no additional cost. :)

Please write an update and submit a PR. I'm moving from Ansible to Chef and would love some real world advice on what Opsworks has to offer me without another dreaded POC. It's likely the original authors aren't using Chef or just use Chef server as I do now.

What's made you move away from Ansible?

Re: Open Guide to Amazon Web Services

#103

A 15-minute scan read of this - specifically the sections on the stuff I've worked with the most - suggests this is a very, very good addition to the official documentation. I would as a minimum recommend anybody/everybody considering AWS to read and think about the "When to use AWS" section. Whilst it is an excellent set of tools that have completely changed the economics of deploying software, there are times when…

Personally, I'm not convinced the price will come down low enough for cloud functions/AWS lambda to ever be cost effective. We've looked at it + API gateway, and it would be orders of magnitude more expensive than our current giant amount of webservers.

Kubernetes (and similar technologies) on the other hand, make it possible to get the same economics as cloud functions while still tying your cost directly to the computing resources you use. Also, it gives you the freedom to (with some pain) move your entire platform to a different provider.

Re: Open Guide to Amazon Web Services

#104
post #11

Wow, the link to http://www.ec2instances.info/ alone is so helpful. I wish I'd had this set of resources a year ago when I spent weeks trying to understand AWS' own documentation.

Upvoted for this link alone. I am so, so tired of the scroll, squint, hunt & jump I have to do on the current Amazon EC2 pricing page to compare costs and features of instances. Especially when trying to compare legacy instances (which we still have a lot of) to newer or VPC ones.

Re: Open Guide to Amazon Web Services

#107
post #84

Great guide. I've been using AWS since there were only a handful of services and it's become increasingly hard to keep up with all the additional ones that have been added in the last few years. EFS had completely passed me by. Does anyone have experience with it? I'm wondering what it would be like to use for Whisper / Graphite (just on a single machine). I'm less interested with concurrent access and more intereste…

The latency is higher than I had hoped. I wrote 10,000 files with 10 kb in each. It took 23 ms per file on average. Then I read them back. That took 8 ms per file on average.

That's way too much for the use case I was contemplating, so I didn't investigate further.

Re: Open Guide to Amazon Web Services

#108
post #11

Wow, the link to http://www.ec2instances.info/ alone is so helpful. I wish I'd had this set of resources a year ago when I spent weeks trying to understand AWS' own documentation.

I will also add https://www.cloudorado.com/ for those who want to also compare against other clouds.

Re: Open Guide to Amazon Web Services

#109

A 15-minute scan read of this - specifically the sections on the stuff I've worked with the most - suggests this is a very, very good addition to the official documentation. I would as a minimum recommend anybody/everybody considering AWS to read and think about the "When to use AWS" section. Whilst it is an excellent set of tools that have completely changed the economics of deploying software, there are times when…

> There are a bunch of apps I'm thinking about building at the moment where I realise a hybrid approach is best: some of GCP's stack, some of AWS', and a small amount of my own bare metal. Knowing when to choose which is not intuitive and comes with time, but there are big, big clues that will help the uninitiated in that section of this open guide.

unless you have a metric shitton of money to blow, there's never a good reason to start with that.

The most expensive part of any of those cloud providers is networking. If you need to transfer data from bare metal aws, you'll need direct connect which charges basically an arm and a leg. Transferring between aws gce is expensive for the same reason. Sure, if you're apple scale and need better data redundancy maybe it's okay. maybe. But that's not an app you think about building as an individual or small company.

I also don't think GCPs stack has anything whatsoever that AWS's doesn't have, so it's odd to mention it in that phrase.

If you'd be so kind as to provide an example application you're thinking about, and the reason each of those is needed for some part of it, I'd be happy to hear it!

Post reply on HN