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

161–170 of 276 posts

Re: AWS mistakes to avoid

#161

Post by rybosome »

nzoschke wrote: post #60
tedmiston wrote: post #44

Earlier quoted context omitted.

I definitely agree that better tutorials and/or a simpler interface would makes AWS more accessible and user friendly. A YC S15 startup, Convox ( http://convox.com/ ), aims to "make AWS as easy as using Heroku." It looks really promising.

Convox member here. Thanks for the shout out. This is definitely a goal of Convox: to remove as much AWS complexity as possible. Our approach matches this guide to a tee. We are using CloudFormation to set up a private app cluster, as well as to create and update (deploy) apps. We are also using ASGs. The instance utilization point is spot on too. The fist thing convox does to make this easy is a single command to re…

Any plans to support the other public cloud providers?

Re: AWS mistakes to avoid

#162

Post by ma2rten »

eva1984 wrote: post #136
late2part wrote: post #132

Earlier quoted context omitted.

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.

It's not easy, but also not every difficult. The company I work for has two Dev Ops (only one until a year ago) and runs on AWS serving millions of users.

We are using MySQL RDS, but are migrating to self-managed Cassandra. We use RabbitMQ instead of SQS. We use Hive/Presto instead of Redshift.

Re: AWS mistakes to avoid

#163

Post by BraveNewCurency »

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.

> Most AWS services are implementations of open source solutions.

This is fundamentally not understanding what AWS is.

- You could say "EC2 is just Xen". But next time there is a 0-day exploit, I'll have AWS working all weekend to patch my servers. And Xen still doesn't have an API for scaling physical hardware..

- You could say "S3 is just Apache". But I will never see a "disk full" message, I will never get paged if something is borked (but it will still get fixed), I will never worry about DDOS attacks, etc.

> Once you implement it yourself on Linux, the ongoing cost drops.

That's like saying "it's cheaper if you change your own oil". Might be true, but doesn't matter. I'm still taking my car in. Lots of other people do. You might try asking them why.

Re: AWS mistakes to avoid

#164

Post by zenlikethat »

jrochkind1 wrote: post #125
larrymcp wrote: post #121

Earlier quoted context omitted.

Hmm. Well, somehow these heavy-hitters have presumably done their research and then chose AWS: https://aws.amazon.com/solutions/case-studies/ I see your characterization of AWS above as "terrible", but I'm curious how that squares with the (probably very well-informed) decisions these people made to use AWS.

I would not "do my research" on the sales site of one of the vendors, if that's what you're suggesting.

The poster is suggesting that the firms listed on Amazon's page did their research before buying, then settled on AWS and felt strongly enough that it was a good choice to make a public recommendation.

Re: AWS mistakes to avoid

#165

Post by bradhe »

meddlepal wrote: post #62
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…

The real issue is that AWS isn't designed as a tool for product developers. Product developers get asked to use it but do not usually have a clue about good systems engineering. AWS was designed for ops and systems engineers first and foremost.

> Product developers get asked to use it but do not usually have a clue about good systems engineering. AWS was designed for ops and systems engineers first and foremost.

Yeah that line is blurring, too.

Re: AWS mistakes to avoid

#166

Post by late2part »

BraveNewCurency wrote: post #163
late2part wrote: post #132

Earlier quoted context omitted.

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.

> Most AWS services are implementations of open source solutions. This is fundamentally not understanding what AWS is. - You could say "EC2 is just Xen". But next time there is a 0-day exploit, I'll have AWS working all weekend to patch my servers. And Xen still doesn't have an API for scaling physical hardware.. - You could say "S3 is just Apache". But I will never see a "disk full" message, I will never get paged i…

Some services are unique. EMR and RDS are not. Others are not.

Outsource if you want. When your bill hits $500k/mo and you realize you're paying for things you can do yourself, your position may change.

Have you been through an AWS outage and been paged? It happens. When you realize your business depends on an opaque organization you may want to diversify.

If you're small it makes sense to outsource sometimes. Not always and not forever.

Re: AWS mistakes to avoid

#167

Post by late2part »

flyt wrote: post #160
late2part wrote: post #156

Earlier quoted context omitted.

Good luck trying to get huge capacity from AWS with no history. Their service limits start low and ratchet slowly, if they have the capacity to give. All these features and elasticity sound nice until you get big and they don't deliver.

This is categorically false. If you have large capacity needs talk to your TAMs/Account Manager and they can make it happen.

It's been true five times in the last three years for me. The elasticity isn't always there and service limits are not always granted when needed.

I don't know what an AWS TAM is but the SAs have tried and failed.

Make a new account and try to run 1000 c4.4xl in parallel for 1 hour. It won't happen.

That's not what happened the five times, but it's illustrative.

And who defines what is a need and what is a want?

Re: AWS mistakes to avoid

#169

Post by jacques_chester »

nzoschke wrote: post #65
jacques_chester wrote: post #47

Earlier quoted context omitted.

As an alternative, Cloud Foundry already drives AWS, as well as Azure, vSphere and OpenStack. Those coming from Heroku will find most of what they want, including buildpacks. Those who want to skip buildpacks can use docker images instead. Disclaimer: I work for Pivotal, who donate the majority of the engineering effort to CF.

Convox member here. CloudFoundry is a really solid platform, but there is a very important distinction between CloudFoundry and Convox. Convox is a very thin layer on top of "raw" AWS. It gives you a PaaS abstraction but behind the scenes is well configures VPC, ECS, Kinesis, Lambda, KMS, etc. For those of us with no need to run on multiple clouds, using pure AWS is simpler, cheaper and more reliable than a middlewar…

Obviously I disagree with the specifics of relative merits. As a nitpick, Lattice was a project to extract core components out of Cloud Foundry into a self-contained unit intended for experimentation, not a standalone component folded into CF.

The feedback was that Lattice is not what developers wanted, so it's been wound up in favour of MicroPCF[1], which is a single VM image that runs an entire, actual Cloud Foundry installation.

When developers decide they want to scale up to any size, they simply retarget a regular AWS/vSphere/OpenStack/Azure CF API server and push again.

I'm sure Convox has a single-VM version I can tinker with on my laptop.

[1] https://github.com/pivotal-cf/micropcf

Re: AWS mistakes to avoid

#170

Post by Rapzid »

vacri wrote: post #56

> There is no reason why you should manage your infrastructure manually. It's unprofessional! It's a mess! Nonsense. Cloudformation has it's issues. It takes time to learn and implement. The templates can break, requiring the stack to be destroyed and remade. In the sample in the article, the database is in the same template as everything else - what fun that will be when an update breaks the template and you have to…

Cloudformation can really be a harsh mistress. I feel I'm constantly discovering good reasons for not including certain sets of resources in the same templates for reasons you and others touch on. And nested stacks? You know, never say never.. Probably never again.
Post reply on HN