AWS mistakes to avoid

Re:AWS mistakes to avoid by jasode on Sunday December 27, 2015 @06:47AM (#10797166)

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, etc.

On the other end of the spectrum, you want to run a high-availability website with failover across multiple regions like Netflix. You need the value-added "services" of a comprehensive cloud provider (the "I" and "S" in "IaaS" as in "Infrastructure Services"). For that scenario, there are currently 4 big competitors: AWS, MS Azure, Google Compute Cloud, and IBM SoftLayer. However, many observers see that Google and IBM are not keeping pace with AWS and Azure on features so at the moment, it's more of a 2 horse race than a 4.

Keep in mind that the vast majority of cost comparisons showing AWS to be overpriced are based on comparing Amazon's EC2 vs bare metal. The EC2 component is a small part of the complete AWS portfolio.[1] If you're doing more complicated websites, you have to include the costs of Linux admins + devops programmers to reinvent what AWS has out of the box. (The non-EC2 services.) Even if you use OpenStack as a baseline for a "homegrown AWS", you'll still need extensive staffing to configure and customize it for your needs. It may very well turn out that homegrown on Linode is cheaper but most articles on the web do not have quality cost analysis on the more complicated business scenarios. Anecdotes yes! But comprehensive unbiased spreadsheets with realistic cost comparisons?!? No.

[1]https://aws.amazon.com/products/

[ Parent | on HN ]

Re:AWS mistakes to avoid by randomflavor on Sunday December 27, 2015 @04:35PM (#10798851)

Digitalocean is a great alternative for simple things.

I use it for dev / early projects and as things get complex or need more redundancy I make the production spend on AWS.

[ Parent | on HN ]

[dead]

Re:AWS mistakes to avoid by dastbe on Sunday December 27, 2015 @11:45AM (#10797917)

Much like I wouldn't trust a person's whose only comments on hn are AWS puff, why should I trust a person whose only posts are Google Cloud puff?

[ Parent | on HN ]

Re:AWS mistakes to avoid by Jhsto on Sunday December 27, 2015 @09:50AM (#10797564)

I've found Google Compute Engine decent, but with App Engine I ran into difficulties with vendor lock-in. I had to first modify my code to get the app run on my local computer. After that I never got it deployed because GAE requires me to bind their own TCP context for outbound connections. This was a shame because I would have wanted to have my app on GAE and database on Heroku.

Just saying that calling 90% of Google Cloud's products to be far better than AWS (or any equivalent provider for that matter) is bold.

[ Parent | on HN ]

Re:AWS mistakes to avoid by lern_too_spel on Sunday December 27, 2015 @02:01PM (#10798351)

App Engine has a lot of faults, but your use case sounds incredibly niche. You're using the multiregion availability of App Engine's HTTP servers but want to use Heroku's single AZ database across relatively flaky, slow internet instead of App Engine's multiregion available database on a managed internal SDN. I'm having a hard time imagining a scenario where that setup would make sense.

[ Parent | on HN ]

Re:AWS mistakes to avoid by obulpathi on Sunday December 27, 2015 @01:39PM (#10798282)

Google Cloud is not just App Engine now. Its pretty much the equivalent to aws in features. Let me also say I have PhD in Cloud and big data (graduated in 2013), worked for Amazon aws, worked for an rackspace for year and half, I was a core contributor to OpenStqck for the products OpenStack Poppy and OpenStack Zaqar. I hope you his puts se more weight behind my statements. If you are interested to know the details and why Google Cloud is better that aws for 90% of products, reach out to me.

[ Parent | on HN ]

Re:AWS mistakes to avoid by matlock on Monday December 28, 2015 @01:13AM (#10800127)

They aren't even close to each other in featuers. All the various additional Services AWS supports go way beyond what Google has at the moment. Numerous Database offerings, Queueing, transcoder, ... Go way beyond what Google has in place.

And no the ability to run it yourself on Google is not the same.

[ Parent | on HN ]

Re:AWS mistakes to avoid by vgt on Tuesday December 29, 2015 @12:21PM (#10807707)

Your statement is simply false.

Here's a material answer - https://cloud.google.com/docs/google-cloud-platform-for-aws-...

In short, Google has parity with AWS on many fronts, and exceeds AWS on many others. Only material AWS advantage at this point is full IAM. Biggest thing you gotta remember is AWS is stuck in "VM" world and only slightly deviates from that. Google's advantage is in its fully managed services, which AWS does poorly (don't tell me Redshift is "fully managed").

Google has Bigtable, which AWS has no competitor for. Google's Pubsub is vastly superior to SQS. Google doesn't need Firehose because Google's services scale to Firehose levels without needing a new product and a new price. Google has Zync transcoder service.

Google has BigQuery, which is vastly superior to Redshift in price, performance, scale, and manageability. Google has Dataflow, which AWS has no competitor for.

Even for VMs, Google offers better networking, faster disks, more reliability (live migration), better load balancer, etc.

And to put the cherry on top, Google's no-committment, no-contract price is only beat if you lock yourself into AWS's 3-year contract.

(disclaimer: work on BigQuery)

[ Parent | on HN ]

Re:AWS mistakes to avoid by subway on Monday December 28, 2015 @12:20AM (#10800005)

Cool story, bro.

[ Parent | on HN ]

Re:AWS mistakes to avoid by a-lex on Monday December 28, 2015 @12:22AM (#10800012)

no.

[ Parent | on HN ]