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

131–140 of 276 posts

Re: AWS mistakes to avoid

#131

Post by late2part »

devonkim wrote: post #127
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…

Most of the reasons to go with AWS as a major strategic decision are to avoid paying for 3-4 (or perhaps... 40+) ops engineers to run and manage so many things that really don't add much business value in themselves and that you could hold to some form of an SLA (especially with enterprise support accounts) and recoup some costs if things came down to it. Furthermore, engineering a lot of AWS services would cost you…

"The cost benefits get better the more incompetent / incapable your internal IT organization is. "

Yes. There will always be a less stupid solution out there that is not as bad as the bad solution.

Or, you could fix IT. But that takes thought.

Easier to give money to a vendor you can blame...?

Re: AWS mistakes to avoid

#132

Post by late2part »

bobbyi_settv wrote: post #126
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…

Linode offers the equivalent of a tiny, tiny subset of AWS. I haven't looked recently, but do they have something equivalent to SQS? Autoscaling groups? DynamoDB? SES? Cloudwatch? If you are going to end up re-building AWS's services from scratch on top of what are essentially naked linux machines (or doing your integration work between services from many vendors), you are doing a huge amount of work that isn't neces…

False. Most AWS services are implementations of open source solutions. Once you implement it yourself on Linux, the ongoing cost drops. With AWS you pay more the larger you get.

Re: AWS mistakes to avoid

#133

Post by mattbillenstein »

sergiotapia wrote: post #123
mattbillenstein wrote: post #108

Earlier quoted context omitted.

I've heard this a few times -- AWS is a very complex product that gives you a lot of freedom in how you build your product using it. I think the web UI works about as well as it could given that complexity. If you want something simpler, you have Heroku and a bunch of similar things which make a bunch of decisions for you -- but you don't have the flexibility there that you do with AWS of course.

There has to be some middle ground between AWS and Heroku though.

There are some options, but the point is, what you're trading for simpler UX is a simpler overall product with less flexibility.

Re: AWS mistakes to avoid

#134

Post by aeze »

discodave wrote: post #113
late2part wrote: post #109

Earlier quoted context omitted.

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?

Their open source alternatives running on Linux?

Re: AWS mistakes to avoid

#135

Post by JabavuAdams »

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…

As an AMZN shareholder, I encourage you to please use AWS. That is all.

Re: AWS mistakes to avoid

#136

Post by eva1984 »

late2part wrote: post #132
bobbyi_settv wrote: post #126

Earlier quoted context omitted.

Linode offers the equivalent of a tiny, tiny subset of AWS. I haven't looked recently, but do they have something equivalent to SQS? Autoscaling groups? DynamoDB? SES? Cloudwatch? If you are going to end up re-building AWS's services from scratch on top of what are essentially naked linux machines (or doing your integration work between services from many vendors), you are doing a huge amount of work that isn't neces…

False. Most AWS services are implementations of open source solutions. Once you implement it yourself on Linux, the ongoing cost drops. With AWS you pay more the larger you get.

What? Implement RDS/SQS/Redshift myself? That is not easy, believe me.

Re: AWS mistakes to avoid

#137

Post by chucky_z »

alttab wrote: post #2

Also, dont use Dynamo unless you have a really good reason. "It scales better than MySQL" is not a good reason. Have fun migrating data and re-indexing constantly!

What about as a kind of Redis stand-in? I'm curious about the DynamoDB PHP session driver.

It sounds like you have a lot of experience with Dynamo. All the use-cases I seem to keep coming up with are more for storing global environment keys outside of the environment itself and using a large number of IAM roles to access individual keys, and as a kind of throwaway 'I need to store this somewhere, but it doesn't really fit in the main DB, and I still need it to persist for at least awhile' case.

Re: AWS mistakes to avoid

#138

Post by jamestnz »

skwirl wrote: post #128
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…

This definitely reads like an ad for Linode to me and it really is turning me off from your company. Does the company know you are posting these comments on HN?

This definitely reads like an ad for Linode to me and it really is turning me off from your company. Does the company know you are posting these comments on HN?

Really? I didn't get that at all.

What I saw was a post giving negative opinions on various aspects of AWS, and stating that AWS' offerings are available elsewhere. There was an example given, of a previous project where he'd switched away from AWS to dedicated physical servers (at an unnamed provider). There was no suspicious boosterism/puffery in the direction of his own employer, like you generally see when a shill is trying to get away with something.

In fact, it seems like the only real mention he made of linode was in the disclosure that he kindly added, pointing out that he worked there and was therefore biased. Most ads don't bother to do that.

If this counts as an ad, then by those standards nobody could ever post in any thread covering the industry in which they work.

Re: AWS mistakes to avoid

#139

Post by JabavuAdams »

late2part wrote: post #131
devonkim wrote: post #127

Earlier quoted context omitted.

Most of the reasons to go with AWS as a major strategic decision are to avoid paying for 3-4 (or perhaps... 40+) ops engineers to run and manage so many things that really don't add much business value in themselves and that you could hold to some form of an SLA (especially with enterprise support accounts) and recoup some costs if things came down to it. Furthermore, engineering a lot of AWS services would cost you…

"The cost benefits get better the more incompetent / incapable your internal IT organization is. " Yes. There will always be a less stupid solution out there that is not as bad as the bad solution. Or, you could fix IT. But that takes thought. Easier to give money to a vendor you can blame...?

This is a fairly naive way of looking at it. Often it's easier to deal with an external organization than to fix your own organization's behaviour.

In a lot of pathologically-managed companies or divisions, there is effectively zero chance of an employee being able changing the pathology.

Re: AWS mistakes to avoid

#140

Post by chucky_z »

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 simply don't believe the $250 - $20,000 month comparison. Could you please provide some real-world numbers/hardware/stack information?

I just did this migration (non-AWS -> AWS), and we saw a ~20% reduction in monthly prices with 1-year contract at AWS vs. physical hosting (admittedly we were getting terrible pricing with our physical hosts, but still). This will be reduced with the addition of t2.nano servers as we run enough t2.micro instances for little odds and ends that it will put a dent in the bill.

Post reply on HN