Hacker News Reader

Comment by chuckcode | Hacker News Reader

I wish AWS would be a little more technical in their product descriptions and announcements. If there was ever an audience that wants technical data about how this type of technology will scale and compares to existing technology like glusterfs it would be the AWS users. Instead the performance specifications are ".. and is designed to provide the throughput, IOPS, and low latency needed for a broad range of workloads." We know that NFS to a lot of nodes is hard, show us that this scales better or am I the testing team?

View on HN

We'll be providing a lot more details later.

Would love some throughput and other performance numbers!

Fair enough, but one of the biggest reasons I ignore these types of posts is because too often they lack these critical details, they come off as puff pieces to me. IMO these posts would hold value for a larger audience if that info was included in them.

It's a upcoming product announcement page from a vendor asking for preview registration, how can it be anything other than a puff piece?

The trick is, based on the title and other marketing tricks, one doesn't find out it's an actual puff piece until one has already spent time reading at least a portion of the puff. By then, you just feel used.

There's a business side for it. Besides recruiting future customers via a preview, you also sublimilaly put off would-be customers decisions until your solution is ready to compete with existing solutions. Microsoft did it very successfully for years.

I can understand that writing up technical details can be difficult as things are constantly improving and also as AWS has to be careful about what they claim. Perhaps a reasonable compromise would be to team up with some 3rd parties to let them try it, optimize a bit with techs from AWS and write up their experiences. Similar to how Apple does the marketing for the iPhone but then lets other people review it. Not perfect but perhaps something that would help the community understand and deploy these technologies better.

I am a huge AWS fan, and user. Look at my accounts for the sums I have spent over the years. I lover new AWS services. But, this is my main complaint with AWS -- don't announce until you have usable numbers and workable examples for early adopters!

On the contrary, the earlier AWS can let you know they're working on a general kind of thing, the better you can plan your own roadmap.

Yea and when is that? If a product is announced, even if its a preview version, shouldn't the details be sorted out by then? This is like a 10000ft view of a product, a great product at that. But numbers to back your claims of scalability and performance would have been best.

Jeff, does EFS have some kind of "backing store" to S3? EFS -> S3 -> Glacier sounds really interesting.

As a developer (but not a sysadmin) I feel the opposite. Not saying your criticism is wrong, just giving another view from a AWS newbie perspective.

When I read most AWS product descriptions, I cannot understand what real world situations they are for. I either could not say, or could only vaguely say, what the product is in my own words. There seems to be a great scaffolding of assumed knowledge about the AWS system and distributed computing. Maybe that's intended, but it's intimidating and keeps me in simpler places like Heroku land.

I feel similarly about AWS and I've been using it for a while. AWS is very powerful and flexible but the number of options and different services can be bewildering. I've suggested AWS to several developers I know that have never used it before and they were turned off from not being able to understand what was being offered and how much it would cost them.

For example, compare the Heroku pricing page and the AWS pricing page for EC2:

https://www.heroku.com/pricing

http://aws.amazon.com/ec2/pricing/

The Heroku one is significantly easier to understand in my opinion. I understand AWS has more options and is therefore harder to summarise though.

I think this just illustrates your point, but EC2 and Heroku Dynos are two different types of services (IAAS vs PAAS). The appropriate comparisons are AWS Elastic Beanstalk to Heroku Dynos and AWS RDS to Heroku Postgres.

https://aws.amazon.com/elasticbeanstalk/

https://aws.amazon.com/rds/

Yes, a link to Elastic Beanstalk would be a fairer comparison of what is being offered by Heroku but my point was most AWS pages are like that and aren't easy to follow, especially if you're new to AWS.

The "you" in the comparison changes as well, though. Indeed, the copy for (say) EC2 isn't comprehensible to the same people that the copy for Elastic Beanstock is. But different people will be reading the copy for those two things. The person AWS is selling EC2 to isn't a newbie developer wanting to run their app; it's someone wanting to build out something like Heroku: someone with lots of system-architecture experience.

Or, to put it more simply: the intended audience for AWS ad copy is exactly the set of people who are currently trying to compare some specific AWS service to similar services of competitors. AWS is never trying to "create a need" for something nobody was already asking for; they're just trying to serve the needs people already do have better/cheaper/more flexibly.

heroku uses ec2 under the hood. heroku is heresy for any competent programmer. despite aws being packaged services at least both managed db and ec2 show you your actual servers and let you choose specs.

Heroku is used by a wide variety of competent programmers. Not everyone wants or needs to choose specs or see actual servers.

Willful ignorance?

I completely agree that the AWS descriptions and documentations are written with the style that actual best practices are left as an exercise for the reader. Without much nurturing the community is left to develop solutions like boto-rsync for moving files into S3 and glusterfs to overcome a 1Tb limit on drives. I'm not sure if that is intentional or a side effect of something else but it certainly turns off a lot of newbies for whom it seems overwhelming and a lot of technical folks as it is difficult to get a grasp on exactly what to use and how in AWS.

Why not have both? E.g. a simple description at the top of the page, and a more advanced discussion below.

Until you see technical details on any file, network or storage system you should always assume your writes (or data for that matter) are/is not safe. It's disappointing to see a product launched and hyped without the appropriate details required to make an informed decision around its use.

I think that you are correct, that some technical details are definitely needed for comparison... To me, this matches up against Azure Files (which is CIFS/SAMBA based)...

Though, even if redundancy isn't a factor, it's nice that you can have network file shares without having to run your own dedicated instance in a given cloud. There are plenty of situations where having a common networked filesystem makes sense across a few servers for purposes of sharing some information, without it being physically on all of them... seeding static content, or user-uploaded files for example. It makes a given solution simpler to implement initially (though other considerations may take hold as a site/application grows).

Typically Azure seems to perform better in terms of storage i/o over AWS. Though, if you are disk constrained in ways you can't reasonable scale horizontally, then you may be better off with something using local disks, and your own backup strategy on something cheaper (Linode DigitalOcean, Joyent, etc).

Aren't seeding static content and user-uploaded files both use-cases that are well-handled by an object store like S3?

Assuming your application was written for something like S3, yes. That's a big assumption though.

Reply on news.ycombinator.com