This is a huge question with far reaching implications that any startup has to ask themselves. Both cloud providers have their own strengths and weaknesses as you would expect. The key is to know what these tradeoffs are and how they will affect you and your priorities.
I wrote previously about DevOps Decision Making and the principles which can be used to make decisions in this domain. This allows you to make an informed and data driven decision instead of relying on gut feeling or advice from acquaintances who may have very different needs and constraints.
Both cloud providers have excellent general reliability as you would expect. But that’s just the baseline minimum required of any public cloud provider today.
What’s more interesting is the ability to architect resiliency into a given application at a cost that’s reasonable. To do this you need to consider all the factors that affect a given service including data stores, networking, load balancers and scaling.
Doing this effectively usually requires some level of cloud specific knowledge and integrations with cloud monitoring tools like AWS Cloudwatch or Google Cloud StackDriver. You’ll also need to make use of cloud specific data stores and load balancing at a minimum.
Based on my experiences, AWS managed offerings such as their Relational Database Service (RDS) are more mature and reliable than their Google Cloud counterparts (Cloud SQL). However Google Cloud is way ahead when it comes to anything Kubernetes related and their Load Balancers perform better under sudden or spiky loads.
Ultimately reliability shouldn’t be a major deciding factor when you are choosing a cloud provider as they can all be architected for reliability. The availability of things like free startup credit incentives and the experience level of your existing team members will outweigh any slight edge in reliability of a specific service.
AWS and Google Cloud are both incentivized to lock you in as much as possible. Any portability they offer only allows you to take you business elsewhere when a more competitive offering shows up.
There are strategies you can use to mitigate this somewhat, but you’ll never be completely free of some level of lock-in. One way to to this is to run your services on Kubernetes, which is supported fairly well by both providers (Though Google Cloud definitely has the advantage here). You can also use tools like Terraform which allow you to automate the setup of infrastructure across both clouds, though you will need separate Terraform configurations for each cloud as they are not interchangeable.
Since lock-in is fairly equivalent on both clouds, this is also unlikely to be a major deciding factor when considering cloud offerings. It is good to be aware of the lock-in phenomenon however and prepare some strategies to mitigate it as you scale just in case you need to migrate to a new cloud due to regulatory issues or client requirements.
Ease of use
Most developers that I know find Google Cloud easier to get started with, while those from a SysAdmin or DevOps focused background appreciate the flexibility that AWS offers. It’s safe to say that Google Cloud is slightly more opinionated and less flexible than AWS, which can be good or bad depending on your perspective.
If you have team members with deep AWS expertise already, then the additional setup and complexity of AWS won’t be much of an obstacle. If all of you are new to the cloud however and coming from a purely development background then Google Cloud may be easier to get started with.
For experienced individuals both clouds are likely to be equally productive in the long term especially if Terraform is used correctly to modularize common infrastructure patterns in your organization. So if you are a startup and need immediate velocity then Google Cloud can be a good choice. Just be aware that some percentage of organizations end up migrating to AWS for one reason or another later in their lifecycle. You can plan in advance for possible migrations so that this is less disruptive if it becomes necessary.
The per unit cost of CPU and memory on both clouds is similar. However a default setup on AWS tends to cost more than the same configuration on Google Cloud. This is because AWS charges more for things like CPU, Memory, Bandwidth and Load Balancers than Google Cloud does.
The extra costs can be mitigated with careful architecture and planning, but as a rule of thumb you can expect to pay a little more on AWS. For many companies the slight extra cost is worth it in order to access a more mature and feature rich ecosystem. Whether you need all the extra features that AWS has is somewhat subjective, but as a rule of thumb most companies won’t see the benefits of the extra features until they begin to scale and service 1000s of users.
Whichever cloud you choose, make sure you look at common cost saving strategies. If you use AWS reserve your VPS and Datastore instances for any resources in use continuously on a long term basis. You will also want to make sure short term non-critical workloads are running on spot instances. Google cloud calls spot instances “preemptible” instances but the concept is similar. With Google cloud reservation discounts are applied automatically based on length of usage so you won’t need to reserve them explicitly.
Autoscaling can also save you a lot of money depending on how uneven your inbound traffic profile is. The mechanisms for autoscaling are similar on both clouds and equally well supported.
I’ve personally used AWS and Google Cloud free and paid support extensively. Both providers have pretty minimal and slow free support. For paid support AWS is far more responsive and helpful. Google Cloud seems to have inherited Google’s general inability to be a customer facing organization.
That said, neither cloud has what I would call “great” support. AWS will actively try to channel you into their consulting partners network for more complex projects but at least it’s an available option if you have the budget for it. With Google CLoud your options are relatively non-existent if the paid support tier fails you (Which was pretty often in my experience).
General lack of support is one of the factors which makes hiring a DevOps partner to help run your infrastructure an attractive option. An experienced consultant in this space will have seen it all before, and probably has private contacts within these organizations in the rare case where things go really sideways.
If all else fails, you can always take to Twitter and Hacker News with your grievances. The results will vary based on the amount of attention your post generates, but it’s a valid last resort option if you have a major issue and nothing else is working.
This is the one category where AWS absolutely dominates. Their certification program turns out reasonably competent cloud engineers at a good clip in the US, Europe and in the developing world where salaries are a bit lower. This means that it’s easy to hire contractors or even full time employees for basic AWS work. I wouldn’t count on a freshly certified course grad for architecture level decisions, but if you have someone more experienced to guide them they’ll be able to work on simple things relatively autonomously.
Google Cloud does have a certification program, but it doesn’t get nearly as much attention as the AWS program. Engineers with Google Cloud experience also tend to reside in more trendy tech areas like San Francisco where hiring competition is fierce and salaries are much higher. That’s not to say you can’t hire engineers with Google Cloud experience, but it’s definitely a more niche skill set and therefore commands higher rates.
If you’re still not sure which cloud to use, feel free to schedule an introductory call with me for free. I don’t charge for these 30 minute consulting sessions and you can bring whatever technical questions you would like. I only ask that you keep me in mind if you find yourself in need of DevOps Consulting Services in the future.
You can schedule a session on my calendar here. These are strictly first come first served, so I apologise if there’s a wait for an available slot.