Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Tips I Wish I'd Known Before I Started

wblinks.com

Post reply on HN
Print view View original

91–100 of 152 posts

Re: AWS Tips I Wish I'd Known Before I Started

#91

Post by richadams »

pnathan wrote: post #61
freerobby wrote: post #55

Earlier quoted context omitted.

Thanks. Does anybody else here agree with this mentality? This seems a major mispractice to me. I've worked at companies with as few as two people to as many as 50,000 people. None of them have had production systems that are entirely self-maintaining. Most startups are better off being pragmatic than investing man-years of time handling rare error cases like what to do if you get an S3 upload error while nearly out…

I agree - it seems off to me. Sometimes you really want to diagnose your problems manually. I'm also wondering how command and control is maintained without SSH access. Is there some kind of autoupdating service polling a master configuration management server (i.e., puppet's puppetmaster)? I can appreciate that ensuring that a typical deploy doesn't require hand-twiddling. That makes sense, lots of it. But not disab…

I think the problem is that I've made it seem like a strict rule in the article; "You must disable SSH or everything will go wrong!!!". It's really just about quickly highlighting what needs automating. Like you say, sometimes you just want to diagnose your problems manually, and that's fine, re-enable SSH and dive in. But if you're constantly fixing issues by SSHing in and running commands, that's probably something you can try to automate.

Personally I always had a bad habit of cheating with my automation. I would automate as much as I could, and then just SSH in to fix one little thing now and then. I disabled SSH to force myself to stop cheating, and it worked well for me, so I wanted to share the idea.

Of course, there's always going to be cases where it's simply not feasible to disable it completely. It depends on your application. The ones I've worked on aren't massively complex, so the automation is simpler. I can certainly see how not having SSH access for larger complex systems could become more of a hindrance.

Re: AWS Tips I Wish I'd Known Before I Started

#92

Post by richadams »

michaelmior wrote: post #50

Disabling SSH is an interesting tip. I guess the OP doesn't do any automation via SSH.

Just disabling inbound SSH connections, the servers can still SSH out to other systems to pull in files, configurations, clone git repos, etc.

It's just a way to stop yourself from cheating and SSHing in just to fix that one thing, instead of automating it.

Re: AWS Tips I Wish I'd Known Before I Started

#93

Post by richadams »

PhilipA wrote: post #10

Really useful article, though I don't agree with not using a CDN instead of S3. There are multiple articles which proves the performance of S3 being quite bad, and not useful for serving assets, comparing to CloudFront.

I'll admit I hadn't really look at this in depth, using S3 without a CDN solved a particular use case I had a while ago, and it just seemed unnecessary to add a CDN in front of it. I've been doing some reading today, and it seems I was wrong. Adding a CDN in front adds lots of benefits I didn't know about!

I'll update the article soon to add in the new information.

Re: AWS Tips I Wish I'd Known Before I Started

#94

Post by banachtarski »

AaronBBrown wrote: post #76
banachtarski wrote: post #65

Earlier quoted context omitted.

Sure. Pop in opscode chef. Took me a weekend to write the basic framework, 3 weeks to make it solid. The 3 weeks more than paid for itself and hosting the config servers with them is a couple hundred a month. I could've hosted it myself too. This includes support for things like a load balancer, heterogeneous nodes (db, app, cache, chat, etc). Ansible, puppet, sprinkler, and the like would take a similar amount of ti…

A bunch of Chef cookbooks does not AWS make. Configuration management tools are of course a necessity in AWS but do not replace their offerings. I'm very impressed that you were able to build in 3 weeks time a low-latency multi-data center application with master/slave database failover, robust fault tolerant load balancing, and backups that can be restored in minutes with an API to control all of those services. Tha…

had master slave, had fault tolerant load balancing, had backup scripts, tested restore procedures. also had node upgrade procedures, and more.

it was more than just chef obviously but chef + any bare metal host environment gets you a large percentage of the way there. Tacking on specific aws services like route53 when necessary works too.

Re: AWS Tips I Wish I'd Known Before I Started

#95

Post by richadams »

freerobby wrote: post #57
richadams wrote: post #54

Earlier quoted context omitted.

This is correct. The tip about disabling SSH isn't about security, it's just about quickly highlighting areas where you're not automated. When developing an application for example, it's often necessary to SSH in to play with some things. But once you've ready to go to production, you want as much automation as possible. Forcing yourself to not use SSH will quickly show you where you aren't automated.

Thanks. I'm a fan of automation but respectfully disagree with this (see my response above for details).

Perfectly valid. This particular tip certainly seems to have caused some great discussion! It worked for my particular case, but I can definitely see it not working for everyone.

I've added a link to this thread to my tip, and expanded on it a little to warn people that it's not for everyone.

Re: AWS Tips I Wish I'd Known Before I Started

#96

Post by ceejayoz »

simonlebo wrote: post #73

Can anyone explain how disabling ssh has anything to do with automation? We automate all our deployments through ssh and I was not aware of another way of doing.

I believe the idea is that by preventing SSH the temptation to just pop in and tweak something manually isn't possible.

Re: AWS Tips I Wish I'd Known Before I Started

#97

Post by toomuchtodo »

jcampbell1 wrote: post #68
micah_chatt wrote: post #58

Earlier quoted context omitted.

"Can you use their queues and database tools w/o using EC2?" Yes, you very easily can. RDS is a simple setup, and so is SQS (queuing). The same goes for Dynamo and Redshift.

Are you really going tolerate 10+ ms of latency between a database, and an app server? I have never personally tried it, but it seems like it would be a disaster.

I just tested pinging our public RDS instance (non-VPC) from one of our EC2 instances that is loading data ever 1-3 minutes from S3 objects into that RDS instance from within a VPC. 3-5ms ping times. More than acceptable.

Re: AWS Tips I Wish I'd Known Before I Started

#98

Post by jessaustin »

mbreese wrote: post #86
jessaustin wrote: post #80

Earlier quoted context omitted.

You're moving the goalposts. First you said: AWS really only makes sense ($$) when you can take advantage of the ability to spin up and spin down your instances as needed. After it's pointed out that other facilities besides EC2 motivate people to use AWS, you can't turn around and complain that those other facilities are useless without EC2. Even if that were true (it's not), such people would be using EC2 not for i…

Who's moving goal posts? After it was (correctly) pointed out that AWS!=EC2 (even though most of the original post was talking about EC2), I asked a simple question - how useful are the rest of the services outside of EC2? It is a legitimate question. I'm not sure how useful everything in the AWS umbrella is outside of EC2. I was hoping to learn something, not provoke anyone.

I guess I misunderstood you; no worries!

Re: AWS Tips I Wish I'd Known Before I Started

#99

Post by berkay »

mbreese wrote: post #45
berkay wrote: post #31

Earlier quoted context omitted.

AWS != EC2. Do not assume that AWS is only used as VMs. It's different for everyone but AWS provides massive savings for many companies. It makes sense for many use cases in addition to elastic workloads.

True, but outside of S3 and Route53, how much under the AWS umbrella is much use without using at least one EC2 instance? I can see a lot of benefit to using S3 without EC2, but after that, I'm not sure what else would be possible. Care to elaborate more? Can you use their queues and database tools w/o using EC2? (If you are using a VPC, maybe?)

Not sure why it has to be without EC2 to be useful. The main benefit is indeed the fact that you can have VMs, queue, load balancers, databases, DNS, cache, etc. all using consistent APIs, etc. You can create dev/test environments that are as close to prod as possible with fraction of the cost, etc.

In our case (and I'm pretty sure we're not in the fringe) when you consider all costs including the administrative overhead, etc. EC2 costs are not significant portion of the cost. Just to give an idea, for us, even if someone had offered VM hosting for free, it would not be cost effective for us to move. For a company that have very high processing requirements it could be a different story. I just wanted to mention that the value added by services in addition to EC2 is sufficiently high that even if EC2 costs are higher than alternative (and they are higher), AWS can still provide significant savings.

Time of a highly skilled dev/ops person is (very) valuable, and not something we can buy more of easily. Anything that saves us time, implement faster pays for itself pretty easily. If you don't have a massive EC2 bill, chances are AWS overall is a good proposition.

Re: AWS Tips I Wish I'd Known Before I Started

#100

Post by mvleming »

mbreese wrote: post #53
AaronBBrown wrote: post #47

Earlier quoted context omitted.

DO, Linode, and Rackspace have lower bottom line costs, but a (much) smaller feature set which means more operational work. Especially when kicking things off, developer and operational time is often far more valuable than the cost of the servers.

Yeah, but it you start out using too much of the AWS tools, you're far more likely to get trapped in the AWS infrastructure and end up paying significantly more in the long term (which is what they want!). I'm not saying that AWS doesn't have useful features, but you need to appreciate the costs of these things before starting. If you need to spend a bit more time on devops in the beginning, then so be it. If you're…

This is off-topic, but because I've just recently started my foray into devops/systems administration do you know any lists of good resources to learn about those two things? I'd love to see a guide like this [1] except that's for analytics.

Things like what you should do right after you SSH into a server, how to make your server secure, setting up nginx, chmod'ing permissions of files correctly, and things I don't even know.

Regardless if you get back to me, I appreciate you taking the time to read this :)

[1] https://segment.io/academy/

Post reply on HN