Ask HN: Which cloud provider to use in 2016? AWS or GCE? Few years ago, I would have chosen AWS over GCE. Now, I am starting new project and need to reexamine which cloud provider to use. If you are starting new project in 2016, which cloud provider do you choose? AWS or GCE? They both seems to provide the services I need such as database, storage, scalability etc. Correction: I meant to say Google Cloud Platform instead of GCE. |
Just be sure to stay mindful of the costs of being on multiple providers. In this example, it doubles your outage footprint, because a regional outage on either provider would disrupt your service. It will also moot some of your cost savings, as you can't take advantage of the free local transfer (e.g. EC2 > Elastic Transcoding > EC2 is free; GC > Elastic Transcoding > GC is not).
Unless there's a specific feature that you need in GCP, AWS is a safer bet from scalability, stability, support and cost.
GCE has an edge on performance, per minute billing, custom machine types, and some datacenters in areas AWS doesn't cover, however they're learning how to be a public cloud, so you will run into beta level bugs, scalability issues, support issues (they also limit how many people can open a ticket in your org), and stability problems. If you do go GCP, make sure you have a rep and a high level support contract, otherwise it's going to be hard when you run into issues.
There's also a handy-dandy TCO calculator that further explores these dynamics here: https://cloud.google.com/pricing/tco
Let me know if any other details would be useful!
One of the most underrated features IMO in AWS is being able to connect services without worrying about passing around, rotating, expiring, etc. any credentials. For instance if you use any of the client or CLI libraries on an EC2 instance, it automatically uses the instance profile credentials. It can also be used to solve the bootstrapping problem of a new instance that needs access to secrets.
(That said, it seems like a huge oversight to me that AWS itself doesn't offer a dedicated secret store to further take advantage of this, since it's something every web app needs. And actually writing the IAM policies can be a bit of a nightmare, it's a whole skill in and of itself to learn to find the 2 or 3 separate docs pages you need to cross-reference to be able to write a policy).
Yes, Google Cloud can manage secrets for you. For example, you can spin up an instance and let Google Cloud handle SSH key creation, copying it to instance, auto-rotating it periodically, deleting it when a user is removed from project, connecting to services from Cloud instances is taken care for you.
If you build inside AWS, you have to pay for cross-region bandwidth like transferring data between the east region and the west region.
If you choose Google Cloud, cross-region bandwidth is also free!
I was blown away by the UX of both the console and the instances themselves. Example: when you add a new user/public key in the console, it propagates to instances automatically. Sure, you could do that yourself, but the default features are just really nice to have.
The code used on Linux to integrate the OS with the platform for ssh keys, startup script, auto-expanding root-disk, etc: https://github.com/GoogleCloudPlatform/compute-image-package...
For Windows, ssh keys aren't supported, however the platform has password reset built-in and starter scripts via metadata are also supported. Here's the code for the Windows agent: https://github.com/GoogleCloudPlatform/compute-image-windows
If running Windows, you will also need device drivers: https://github.com/GoogleCloudPlatform/compute-windows-drive...
Places where Google Cloud shines over AWS: Excellent UI, Ease of use, Scalability, Security, Data services, Big Data, Machine Learning, Network, Disks. The only place where Google loses to AWS is Relational Databases.
Google Cloud Network and SSDs are about an order of magnitude better (in terms of performance / price) compared to AWS Network and SSDs. Googles Big Data tools (BigQuery, PubSub, Bigtable, Dataflow) can scale to petabyte scale without any problem. AWS can be OK for terabyte scale data workloads, but beyond that, it's hard to scale and manage. Other pieces like Kubernetes, TensorFlow and Dataflow (Opensource, if you want to run in-house) and available as native Cloud services, all services are fully managed makes Google Cloud the best Cloud.
AWS is far ahead in terms of maturity of the service, breadth of services, ecosystem support.
On the other hand, Google Compute Platform is "up and coming", and in general it is trying to attract customers by offering lower-than-AWS prices on most comparable services.
AWS is also a safer bet. At the same time, Google is big enough that betting on it is not as risky as betting on another "startuppy" provider.
Compare instance launch times. Compare internal network performance.
I just cannot fathom using AWS for a new project. I guess if you MUST have some of the SAAS apps built on top of AWS and don't want to consider how you would run the same thing on GCE... but I think GCE would be a fantastic default cloud for 90% of people.
Given that no company that I work with uses Google's cloud, I'm curious who is using it. They're marking hard obviously. Makes me wonder what's an ad and what's not.
GCE is preferred for any kind of big data or analytics scenario. It's a cheaper service with way better networking or disk io, fit's very well for an engineering oriented organisation. Per minute pricing or very fast scaling of the services are huge advantages.
GCE is interesting however, I'll definitely keep that in mind for future "testing" but at the moment I'd take AWS as my "out of the box"-solution.
AWS is what we use for cloud provisioning, with Rackspace still hosting some legacy systems. We are moving our workloads off Rackspace as the cost is higher. Azure is a possibility but unlikely as they are as expensive as AWS and offers nothing that we feel is especially compelling as a Linux shop.
If Digital Ocean, Linode or similar offered an Australian hosting option I would be willing to look at it if the cost was under 2x that of a US region, as I could get a similar functionality having SaltStack handle provisioning. However knowing bandwidth and related costs in .au I really doubt many want to go through the cost & effort.
Most of the domestic providers are either too expensive ($40-$80 AUD a month for a 1 core / 1gb instance w/ HDD backed storage & 100 GB transfer), and/or aren't run to the scale that you can have confidence that they will be an ongoing competitive business.
It seems much less expensive than paying a fee for a big Google Drive. The bandwidth needed for GCStorage would be minimum (just uploading from time to time)
And if I'm already locked in to AWS for one service...
They appear to be PCI DSS v3 compliant?
If I am not mistaken, using GCE means you are locked in and cannot migrate away easily. That's why I never looked into it closely. I don't want to be at the mercy of a provider.
GAE ~= Elastic Beanstalk
Azure Virtual Machines ~= Google Compute Engine ~= Amazon EC2
Azure Websites/App Service ~= Google App Engine ~= Amazon Elastic Beanstalk
Like much enterprise software, the new side-scrolling mess which hides necessary information has the distinct smell of something that was built to sell on golf courses to clueless middle and upper management, and not for people who actually need to do the work. The load times are horrible because of the number of HTTP requests and the weight of their payloads, making it practically unusable on, say, plane wifi or tethering outside of LTE service.
Practically this might not be the worst thing ever, because it might encourage people to describe their infrastructure as code instead of a pointy-clicky mess, but sadly this still appears to be outside the Microsoft-blessed way to do things - so most never will.
Absolute shit experience, the worst I've had with a major platform. We went back to paying $250 / mo to DigitalOcean, despite being a bootstrapped startup with no money that hasn't paid ourselves in 18 months. That's how bad it was.
Their SSD story was late and pathetic. At first, they started offering SSD ... as temp volumes. Zero real-world use cases (except as a SQL 2014 "Buffer Pool"). Like, why would you even announce such a weak offering?
Then they added full SSD ("Premium Storage"). You need special instances to use SSD, it's not just a bit you flip on your storage options. AND, you need to pick 1 of 3 sizes. If you need something between, round up. Need more performance? They suggest you software RAID things together. It's laughable.
Everything is SLOW. Machines take forever to start up. Windows boxes often enough get stuck, requiring resizing (change to larger, change back to orig size) to get them unstuck.
The networking is dumb. "Cloud Service" = 1 public IP, then each VM gets NAT'd. This is a holdover from when Azure thought they could PaaS their way to fame. Oh, I tested restoring an Elasticsearch backup that was stored on Azure blob storage. Restoring to a GCE instance went about 10x faster.
Pricing is very high. On some instances, GCE was 10x cheaper, though the average was like 2-3x and that was including Azure's "enterprise" discount.
Azure is squarely aimed at old MS-style customers that want "cloud" and don't really know more than that. "Ooh Hadoop... in the Cloud!" That kind of thing. They know they can make a killing by just migrating on-prem customers to their own thing. And they're probably right. Why would an enterprise with a big AD deployment decide to take a risk by not going with Microsoft?
Oh and did I mention the portal will cause depression and frustration? Cause it will. It's beyond comprehension how anyone thought it was a good idea. Oh, and there's 2 of them. The old one is not-as-bad and last I checked, was still needed for things they didn't include in the New Tablet Edition Portal.
You literally could not pay me to use Azure over GCE: I was looking at something that might get BizSpark Plus, with $$$$ in free Azure credits, and it wouldn't be worth it.
Edit: Oh another awesome part. Global Namespace! Everything you create is scoped globally, so if you're naming things like mysite-web-1, better hope no one else decides on that prefix too. But hey, maybe it's 2016 and we're supposed to use guids for names and container managers so this doesn't matter. Just another poor decision decision.
I know I accurately summarize many of my coworker's opinions when I say: Fuck Azure.
Disclaimer: I used to be a huge MS fanboy, and I still really dislike Google as a company. If I sound bitter and biased, it's because I've dealt with Azure for ops for around 2 years and they've earned it. I've less exp with GCE but it's been so, so, refreshing. Like a cool minty breeze.
The ease of certain things (the integration with Visual Studio for example) simply surpasses anything I've played with for Amazon. I use the portals less though, and mostly rely on the tools provided in Visual Studio (explorers, deployment managers etc).
- instance needs to be force stopped, that doesn't always work in the AWS console, you have to open a support case
- scaling things up: s3 buckets that get sudden amounts of traffic need to be manually partitioned, ELBs as well
- they have more logs on the backend you can't see: ELB logs aren't complete for example, they have more detailed logs only support has access to
- RDS failovers: determining if a RDS failover was due to a maintenance period or a hardware problem
- SNS/SQS errors: 5xx from SNS/SQS due to backend issues you have no control over
- Accidently used the official CentOS AMI? Oops, that AMI is "locked" and doesn't let you mount the image on another instance to get your data, you have to use support to get them to remove market codes
- New instance types don't alway boot correctly, this happened with i2s, they'd just fail to boot sometimes
- Accidently use CloudFormation to deploy your stacks? Lots of support tickets to fix all the backend problems with that, but at least Terraform solves that now :)
https://cloudplatform.googleblog.com/2016/03/announcing-two-...
BGP is an awesome feature for my use case (mail), but unfortunately 32gb instances aren't available in Sydney and one of the virtual appliances I run have that as the recommended config for the traffic level I am pushing. Other feature that would be really good would be some bulk storage to hold backups on (in addition to the automatic backup feature). Additional Block storage isn't available in SYD.
Thanks for the recommendation.
Something worth monitoring, thanks.
Not just the performance, all Google Cloud services are fully managed (Think of S3 and Lambda on AWS). No servers! On AWS, only a couple of services are fully managed. Rest of them are a thin layer on top of EC2. If AWS is DevOps, Google Cloud is NoOps.
https://docs.google.com/presentation/d/1B1jvWWh0ACaDv4ryEzLl...
Nice, I really like that way of putting it. The promise of the Cloud is, indeed, that it is supposed to abstract you from that, but Reserved Instances reveal what is actually happening behind the curtain.
k8s master, or any number of internal tools.
There is no harm with the discount. The harm is only with lock in. Once you reserve instances, you can not change the type (different CPU / memory ratio), region or the number of instances. Once you reserve, you have to pay for your instances 24x7, whether you use it or not. If you require more capacity than reserved, you need to pay the full rate. If you require less capacity, then you need to pay for the unused capacity. You don't have all these headaches with Google Cloud pay per go and automatic discounts. You simply use as many resources as you want and you get the discounts automatically.