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

AWS mistakes to avoid

cloudonaut.io

Post reply on HN
Print view View original

111–120 of 276 posts

Re: AWS mistakes to avoid

#111

Post by CaptSpify »

CharlesW wrote: post #106
ddevault wrote: post #103

Full disclosure: I work for Linode and I am super biased. This is my own opinion etc etc Perhaps the first AWS mistake you might make is... using AWS? Even before I started at Linode, I thought it was terrible. It's extremely, unreasonably pricey. The UI is terrible. Their offerings are availble elsewhere. I started MediaCrush, a now-defunct media hosting website, on AWS. After a while, we switched to dedicated hosti…

I feel like you wouldn't be too pleased if a super-biased Amazon employee posted a similarly anecdata-filled post about Linode. Is it really a smart idea to bad-mouth AWS in a post that really doesn't intersect with what Linode provides in any substantive way?

Considering he put the disclaimer that he is super-biased up front, I personally appreciate the insider review

Re: AWS mistakes to avoid

#112

Post by Sir_Cmpwn »

tshtf wrote: post #105
ddevault wrote: post #103

Full disclosure: I work for Linode and I am super biased. This is my own opinion etc etc Perhaps the first AWS mistake you might make is... using AWS? Even before I started at Linode, I thought it was terrible. It's extremely, unreasonably pricey. The UI is terrible. Their offerings are availble elsewhere. I started MediaCrush, a now-defunct media hosting website, on AWS. After a while, we switched to dedicated hosti…

In the past during security incidents (and there have been more three than major ones in as many years), there has been absolutely no transparency from Linode management. That's more than enough reason for serious customers to avoid Linode...

I don't think it's appropriate for me to comment on security incidents (before my time, anyway), but I'm not trying to sell people on Linode here. MediaCrush was actually using a combination of Voxility and Digital Ocean (and Route 53, actually). There are lots of options, guys.

Re: AWS mistakes to avoid

#113

Post by discodave »

late2part wrote: post #109
cle wrote: post #107

Earlier quoted context omitted.

There's a lot more that goes into the decision than service costs. There are lots of other costs that must be considered. E.g. if using AWS can save you one employee, that alone might make it worth the extra service costs. I'm not saying you're wrong, just that your analysis is incomplete.

I'm sure there's a situation where AWS saves money on TCO. If you ever find it, please let us know.

Umm, does linode offer higher level services like SQS, Lambda, SWF and friends?

Re: AWS mistakes to avoid

#114

Post by busterarm »

ddevault wrote: post #103

Full disclosure: I work for Linode and I am super biased. This is my own opinion etc etc Perhaps the first AWS mistake you might make is... using AWS? Even before I started at Linode, I thought it was terrible. It's extremely, unreasonably pricey. The UI is terrible. Their offerings are availble elsewhere. I started MediaCrush, a now-defunct media hosting website, on AWS. After a while, we switched to dedicated hosti…

AWS hands out credits like candy and there's tons of ways to get AWS credit or earn it. I wouldn't be surprised if cash-strapped startups built on AWS credit to go out and get funding and then just never move off of it.

Re: AWS mistakes to avoid

#115

Post by Leon »

eropple wrote: post #86
skywhopper wrote: post #59

Earlier quoted context omitted.

Strongly agree. Support for new AWS features hits Terraform much faster than CloudFormation (still waiting for CF support for AWS's managed ElasticSearch service that was unveiled two months ago--Terraform got it right away). Some of the critiques below are true... HCL is fine, but Terraform's interpolation syntax has a long way to go. That said, CF's JSON is way more painful to deal with. As for the other problems,…

> HCL is fine, but Terraform's interpolation syntax has a long way to go Oh, HCL is fine, you say so authoritatively? Well then do me a solid and show me an if statement, show me a for loop. Because you're not building nontrivial, reusable infrastructural modules without logic. I know. I've tried. I've committed, between different projects and clients, somewhere around ten thousand lines of Terraform and probably hal…

I believe you can hack an if statement by doing a length, substring and equality comparison to make it equivalent.

Re: AWS mistakes to avoid

#116

Post by late2part »

kartan wrote: post #57
zerotosixty wrote: post #7

You know what I've realized that's really important. More AWS tutorials is really needed. There's numerous of new programmers who want to learn AWS, but can't finish building anything because they get buried in documentation. I find there are a lot of high-level abstracted tutorials, but for the new services, there aren't a lot of detailed tutorials. For instance, an implemented cognito->gateway->lambda->dynamodb is…

> There's numerous of new programmers who want to learn AWS, but can't finish building anything because they get buried in documentation. I agree partially. In the end the documentation is what you are going to need to read sooner or later. Or trainings equivalent to that documentation. Good tutorials are good for starting, but doesn't make you a professional. I guess that in 10 years any one will be able to create w…

AKA what happens when you take a bunch of God complex programmers and set them loose operating production infrastructure on the Internet?

Re: AWS mistakes to avoid

#117

Post by tedmiston »

nzoschke wrote: post #85
davidbarker wrote: post #74

Earlier quoted context omitted.

I hadn't heard of Convox before, but it sounds interesting. I'd like to use AWS more, but each time I tried to get into it I felt overwhelmed. I currently use PagodaBox a lot, which is great (most of the time) because it handles a lot of the complexity for me, but it can often be expensive. How does Convox compare to PagodaBox?

I've never used PagodaBox but it looks like a nice PaaS. Convox has the same goal of a PaaS: to give you and your team an easy way to focus on your code and never worry about your infrastructure. One big difference with Convox is that we accomplish this with single-tenant AWS things. You and your team's deployment target is an isolated VPC, ECS (EC2 container service), and ELB (load balancers). If you're asking for a…

So eventually Convox will have to make money, but I'm not sure I see the path... given that I have free access to the software and the infra is provided by AWS.

Do you plan to eventually charge a monthly fee for using the command-line tool?

Re: AWS mistakes to avoid

#118

Post by discodave »

tomglindmeier wrote: post #93

I wonder if AWS is a good location to run a VoIP server. VoIP is a real time application that is very prone to jitter, latency and packet loss. I'm concerned about "noisy neighbors" and decreased network performance at AWS. Does anybody have experience with running a VoIP (e. g. Asterisk) on AWS?

If you're willing to pay, then you can avoid the noisy neighbor problem almost completely by using c3.8xlarge or c4.10xlarge instances. Those instances get their own dedicated 10G NIC. You can use reserved instances to reduce the cost.

But even with smaller instances, AWS network performance is going to be about the same as any VPS provider. The only way to get guaranteed performance is to do Colo, which is expensive.

Re: AWS mistakes to avoid

#119

Post by late2part »

busterarm wrote: post #114
ddevault wrote: post #103

Full disclosure: I work for Linode and I am super biased. This is my own opinion etc etc Perhaps the first AWS mistake you might make is... using AWS? Even before I started at Linode, I thought it was terrible. It's extremely, unreasonably pricey. The UI is terrible. Their offerings are availble elsewhere. I started MediaCrush, a now-defunct media hosting website, on AWS. After a while, we switched to dedicated hosti…

AWS hands out credits like candy and there's tons of ways to get AWS credit or earn it. I wouldn't be surprised if cash-strapped startups built on AWS credit to go out and get funding and then just never move off of it.

Correct. Lock-in is a key part of their strategy.

Re: AWS mistakes to avoid

#120

Post by softdev12 »

elwell wrote: post #55

I'd like to add, if using Elastic Beanstalk, don't directly attach an RDS instance when creating the environment. If you do, you won't be able to destroy your environment without also deleting the RDS instance. Instead, create the RDS instance separately, and just add the proper security group for the environment to be able to access the host. Then you can easily create a new eb environment with any config changes (t…

interesting. i was under the impression you could just create a snapshot (before destroying the environment) and then restore as needed. am i missing something?

Edit: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_R...

Post reply on HN