Live data from Hacker News

AWS mistakes to avoid

cloudonaut.io

201–210 of 276 posts

Re: AWS mistakes to avoid

#201

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?

I sell an application built around VoIP. I dislike running my own servers, so just lately I moved them to AWS.

At first, I used instances that were not very performant, causing some problems. I quickly moved to more powerful instances and since then there have been no problems at all. There is a slight delay, which is normal, since the servers are not in the same country as the users anymore, but the users haven't noticed it at all.

I can't say how well it scales, though. I have a small user-base, so scaling has not been a problem yet. Network performance might become a problem if you have a huge user-base.

Re: AWS mistakes to avoid

#202

Earlier quoted context omitted.

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.

It is very difficult to run it at AWS's scalability, reliability, security and automation level. These all cost money and/or time. Not all companies require these features to the same extent, of course, so AWS is not always the right choice, but it isn't always the wrong choice either.

Re: AWS mistakes to avoid

#203

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…

If you're just using AWS for EC2 then you're probably better off with another provider, but I think the key advantage AWS has is in the 'WS' part of their name.

Cloudwatch, SQS, SNS, Dynamo, S3 etc offer good managed services that you can plug into your applications/systems with not that much effort - and crucially very little OPS needed.

Re: AWS mistakes to avoid

#204

Earlier quoted context omitted.

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

I have heard of a few poorly managed companies pulling out of ruin by using consultants and third party labor to supplement their collapsing workforce. But I've seen poorly managed companies on occasion fire their executives and stabilize as well. People love to spend 7 figures on consultants and refuse to take their advice in favor of suck-ups that recommend that they just slightly change what they're doing or just sit in silence and continue to bill out. This is why I stopped consulting / contracting in the federal government space - nothing I do even if I was a company founder can fundamentally fix even a tiny fraction of the deep flaws. People got rich off of manipulating contracts to do as little as legally possible while the best at delivering were cut because they actually finished the job right. Reward for failure is a system that exists plenty in the private world, but only in public sector is it institutionalized.

Re: AWS mistakes to avoid

#205

Earlier quoted context omitted.

AWS is insanely overpriced. It's weird to me that everyone jumping on AWS and some of their customers never come close to attracting the internet traffic required to set up CloudFormation. I think if you're starting a webapp out of your own pocket and not millions of dollars of investors, it makes sense to save where you can. Using locust.io, I've seen that my current site on two $10/month Linodes can scale up to app…

What are some alternatives to AWS? Are there realistic alternatives?

Please take a look into Google Cloud. It's now feature equivalent with AWS (https://cloud.google.com/docs/google-cloud-platform-for-aws-...). Google Cloud is better than AWS on all fronts other than Relational Databases. Google Cloud has MySQL only. AWS has MySQL, PostreSQL, Oracle, MSSQl. Rest of the services Google beats AWS by a fair and wide margin. I have done a fair amount of benchmarking Google vs AWS in past 3 months and conclusions are shocking. With Google Cloud, you can save about 50% of your bill (I have taken into account of reserved instances), huge increase in companies agility (Speed in taking decisions like capacity planning, instance type, sizing, zones, cluster sizes ... due to simplified infrastructure and pricing & performance wise too, blazing fast disks, live vm migration), far better security (data encryption at rest and on wire by default for all products, ssh key management). I am presenting my findings at our meetup group (http://www.meetup.com/Cloud-Big-Data-and-Data-Science-Group-...) in a couple of months. If any of you want to talk, reach out to me at obulpathi at gmail.

Re: AWS mistakes to avoid

#206
post #197

Earlier quoted context omitted.

What are some alternatives to AWS? Are there realistic alternatives?

The "alternatives" depend on your situation. Picture a continuum between brain-dead simple websites and business-critical complex websites: simple: static website, WordPress blog moderate: small business CMS, etc complex: Netflix, AirBNB If you're running a simple WordPress blog, the AWS prices are absurdly overkill. For this use-case, there are a zillion alternatives. Linode, Digital Ocean, Rackspace bare metal, etc…

If you look at the speed at which Google Cloud has been adding products for past 6 months, you will be amazed. Google Cloud is now feature complete with AWS and 90% of its products are far better than AWS.

Re: AWS mistakes to avoid

#207
post #173

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…

$20k/month is $240k/year, which is at least two developer salaries. Do you really need two full time devops/whatever to manage the open source equivalents to the AWS services? Aren't there tools that can provide a similarly high level/seamless/polished experience running on your own computer, using your choice of cloud provider as the backend? If not, why not? (I wouldn't know - I don't even run a website, and if I d…

Look into Kubernetes. Since everyone is migrating to Docker and Microservices, Kubernetes provides a perfect fit to run your workloads on local premise and then migrate to Cloud when extra capacity is needed. It's opensource and supported by several vendors.

Re: AWS mistakes to avoid

#208

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'm working at a medium, growing startup and wonder when/why to use AWS? We currently use a mixture of root servers (DB) and VPS (App, HAProxy, NGinx) at a hoster. * We use a Docker/Consul/Nomad/SaltStack setup to install new servers for replacing broken ones and growth * App setup is Redis/Disque, Postgres(DB, BI) and app servers * New dedicated servers we get in around 1h, VPS in around 1min (Only VPS over API) * W…

0.2 Full-time employees to build all the automation, scale up (and down!) the stack as needed, monitor, operate and maintain it at an HA level? That is a huge feat, and I'd love to read about how you pulled it off. Please consider sharing your story, and perhaps your Salt recipes ;)

With all those things that you have in place, AWS would not be a big win for you, though you still might find some use of AWS services like S3 for reliable object storage, Route53 for DNS, or Lambda for "server-free" event handling. The unique thing about AWS is the huge portfolio of services they have and the absolutely amazing rate at which they manage to pump out new (and useful!) ones.

Re: AWS mistakes to avoid

#209
Personally never quite got the appeal for EC2. You're basically replicating what you would be doing on physical servers anyway. The real productivity gains come from using a fully managed PaaS (Heroku, Azure Web Apps, Google App Engine, OpenShift etc.) where there is no maintenance and scaling and redundancy is taken care for you. Granted those are even more expensive but they are the only ones that provide any kind of value.

Re: AWS mistakes to avoid

#210

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.

There are also quite a few Ansible core modules for EC2 if you're looking for a uniform way to manage your resources outside of the AWS GUI, although to be honest I'm not sure if that's "easier" so much as more flexible. Still solves the problem with mistake #1.

Try Kubernetes may be?
Post reply on HN