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

51–60 of 152 posts

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

#51

Post by AaronBBrown »

banachtarski wrote: post #46
AaronBBrown wrote: post #21

Earlier quoted context omitted.

As someone who has worked w/ AWS (and Rackspace) for several years with multiple startups... Unless they have dramatically improved their offering in the last couple years, an hour or two from "I need a new server" to delivery is 1) not an accurate timeframe for physical servers from Rackspace and 2) even if it was realistic, that's an eternity when you are trying to iterate quickly. I can have a new server in 30 sec…

You speak as though ops and automation is too mysterious for a startup to handle. There are so many tools and frameworks that do what AWS does that it's easy to acquire that expertise. And who says you always need a new server to iterate quickly? I moved my last company completely off AWS and it was proven to be a great decision across a number of dimensions.

Can you list some of those tools and provide an estimate of how long they take to configure and how much day-to-day support they require?

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

#52

Post by pmh »

riffraff wrote: post #41
paulgb wrote: post #9

Earlier quoted context omitted.

Also, if you change the first line of http://wblinks.com/css/style.css to @import url(http://fonts.googleapis.com/css?family=Droid+Sans:400,700); you should notice an improvement in the boldface font rendering. Great article, btw.

OT, but how does this work? Why does it improve rendering? Is it downloading both the normal and bold weight rather than only one leaving the browser to do the rest?

>Is it downloading both the normal and bold weight rather than only one leaving the browser to do the rest?

Yes. The original URL only provides the normal weight (400), but you can specify other weights/styles[1]. 700 is the weight for bold and GP's URL requests both 400 and 700.

[1]: https://developers.google.com/fonts/docs/getting_started#Syn...

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

#53

Post by mbreese »

AaronBBrown wrote: post #47
_zen wrote: post #26

Earlier quoted context omitted.

> particularly when you are a new startup and don't have enough information (or capital!) to make educated server purchases. I doubt there are many founders who are technically informed enough to know about Amazon Web Services, but don't know about the other big 3 (Digital Ocean, Linode, Rackspace). If you truly don't, then you must not be a tech company, and I have a hard time believing a non-tech company without an…

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 starting a company, there had better be some good reasons behind using AWS, aside from "because faster iteration, developer time!".

Specifically - what AWS features do you find to be useful at the beginning? You seem to have some specific use-cases in mind. I'm legitimately curious.

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

#54

Post by richadams »

pavel_lishin wrote: post #37
freerobby wrote: post #34

Can you (or somebody else) elaborate on disabling ssh access? Is this a dogma of "automation should do everything" or is there a specific security concern you are worried about? What is the downside of letting your ops people ssh into boxes, or for that matter of their needing to do so?

Based on the article, it seems it's there to make sure that you're automating everything, instead of logging in to do that one little thing by hand.

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.

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

#55

Post by freerobby »

pavel_lishin wrote: post #37
freerobby wrote: post #34

Can you (or somebody else) elaborate on disabling ssh access? Is this a dogma of "automation should do everything" or is there a specific security concern you are worried about? What is the downside of letting your ops people ssh into boxes, or for that matter of their needing to do so?

Based on the article, it seems it's there to make sure that you're automating everything, instead of logging in to do that one little thing by hand.

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 of disk space. There's a good reason why even highly automated companies like Facebook have dozens of sysadmins working around the clock.

I thought all of his other points were spot-on but this one rings very dissonant to my experience.

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

#57

Post by freerobby »

richadams wrote: post #54
pavel_lishin wrote: post #37

Earlier quoted context omitted.

Based on the article, it seems it's there to make sure that you're automating everything, instead of logging in to do that one little thing by hand.

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).

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

#58

Post by micah_chatt »

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?)

"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.

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

#60

Post by NathanKP »

mbreese wrote: post #11

I'd also add to the list - make sure that AWS is right for your workload. If you don't have an elastic workload and are keeping all of your servers online 24/7, then you should investigate dedicated hardware from another provider. AWS really only makes sense ($$) when you can take advantage of the ability to spin up and spin down your instances as needed.

The startup I'm working for has minimal scaling required but we still use AWS despite the higher cost for EC2 because the broad ecosystem of AWS products make it easier to develop interesting things quickly and efficiently.

If we went with all of our own dedicated hardware, or cheaper instances from a different cloud provider then we'd miss out on ELB, have slower and more expensive communication to and from S3, not to mention that services like Elastic Beanstalk make deploying to EC2 instances very easy compared with rolling your own deployment system. And for those who don't want to bother with administrating databases and cache machines RDS and Elasticache are going to be cheapest and fastest if your instances are EC2.

So yeah I agree that EC2 is expensive, but the benefits of living fully within the Amazon ecosystem are pretty large.

Post reply on HN