I believe that whatever GCP does, does better. Faster network, faster spinning and turning off servers, simpler quotas, etc. GCP doesn't offer that many services as AWS and most of those are not very compatible with Apache tools (although they're doing their best, e.g. BigTable looks like Hbase from outside).
In our case, we're running ~28,000 servers on GCE and utilizing many services, especially PubSub, BigQuery, etc. The price we're paying for our setup is roughly 1/4 of a similar setup on AWS.
Additionally we're running our search engine at top of it with couple of other services.
You can check what we're up to here https://pex.com
Uhh, Google will terminate preemptible instances whenever they need the resources as well. Hence the name, "preemptible."
Also I personally find much easier to understand is the pricing. It's very consistent and simple. Preemptible servers are discounted by 80% from the regular ones. On AWS the price changes, also they only offer older generations while GCE offers any type at the same discount.
Disclosure: I work on Google Cloud (but not compliance).
TL;DR:
- Google's global SDN is ultra-secure, and Google carries your packets on its network rather than dumping them onto public web. Google's undersea cables are shark bite-proof! [1]
- Google Data Centers are mostly homogeneous and rely on Google-build hardware rather than vendors. This greatly helps with securing infra - only one vendor (Google) to trust, only one set of best practices to follow, lower risk of misconfiguration, and exposure risk is minimal.
- > 600 security engineers.
- Encryption-at-rest and in-transit is ubiquitous.
[0] https://cloud.google.com/security/whitepaper
[1] https://www.youtube.com/watch?v=XMxkRh7sx84
(work on Google Cloud, not in marketing :) )
For security, I don't care whether my traffic as routed over a private network or public web as long as the data is encrypted, because a "private network" is only as private as thousands of miles of fiber and every single network facility it traverses can be. Which means 'not very'.
Does Google build it's own hard drives/SSD's and CPU's? If not, then that's at least 2 other vendors to trust since both CPU's and hard drives are related to hardware security.
On your first point. There is a very strong risk of inadvertent misconfiguration or your employees not following best practices.. Or even poor documentation. Google cloud by default gives you a global secure vpc that never traverses public internet, so there's less risk because the baseline of security is high. Sure, you can run VPN tunnels between data centers. Point is, with Google cloud you don't need to.
On the latter point, of course you cannot eradicate every vendor, especially within the obvious context of this specific Intel announcement... But, again, not having three dozen flavors of configs and four network router vendors does make a difference. I would encourage you to read the paper I linked to above (discussed this topic in great detail), and also perhaps [0].
Also security folks at Google, who are much more qualified to discuss this topic than I am, frequently post on hn. [1]
[0] https://cloudplatform.googleblog.com/2016/02/Google-seeks-ne...
It's also important to pay attention to which services you consume, as not all of them are certified to the same degree.
Technical management can sometimes be persuaded, given overwhelming evidence, that competing products/services are superior or more cost-effective but ultimately conclude "we'll never sell this solution to leadership".
The only thing I really miss from AWS is RDS's postgres.
I don't even want to talk about Azure.
Why do people use AWS? 1. Free tier. 2. Plethora of PaaS as you mentioned. 3. AWS was there first, has brand recognition and is a safe choice for management.
It's superior for running Windows at least, right?
Disclosure: I work on Google Cloud (so I want to sell you our services).
I'm working on a migration to it, so I'm not very experienced with it, but so far, it's been very painful compared to GCE or AWS, in which I've run production stacks. I'd rather not comment further, simply due to my relative new-ness to the service and the chance that it's just lack of experience. The customer service is, at best, run at a glacial pace.
> "It's superior for running Windows at least, right?"
I'm a Linux guy running a platform agnostic Linux stack, but I'd assume so. I get the feeling so far that it's really good if you want to run MS-SQL and .net, and garbage otherwise.
The only reason we're migrating from GCE to Azure is because our GCE credits are expiring, and Microsoft gave us the YC Credits offer for Azure. We'd rather stay on GCE if we could. Also, postgres RDS/CloudSQL is the one thing we miss from AWS
Disclosure: I work at Microsoft; opinions are mine.
I wasn't going to lay it out here, but, as I have your ear:
I'm not saying it's impossible to run a Linux stack on Azure - but man, trying to image the machine, for example, is a whole rigamarole.
Want to run your own image on a scale set? Oh, well, you need to craft a JSON template, by hand. There also appear to be limits on how many machines can run off an image.
ARM is a a mess (IMHO), and it's impossible to select a custom image when creating a new resource group. It also seems (correct me if I'm wrong) impossible to change the vnet of a VM/ARM after it's created. it also seems like ARMs can't share an existing vnet. Again, please, correct me if I'm wrong. I'm new to this service.
I may have to drop to running a bootstrap script to get my stuff working, but the idea of doing a curl | sh is pretty horrific to me, from a security perspective.
Non MS-SQL as a service? Nope.
The new managed disks are very nice. I like those a lot :)
Also, Azure times out my ssh sessions :(
When I last chatted with our Account Manager I mentioned Postgres, yeah. We're currently running our own on GCE, but it would be awesome to have it aaS, with replicas and automated backups that I don't have to keep an eye on all the time :).
For anyone else who is on AWS (maybe because of rds postgres, or because it's client work that needs to be on AWS), you can go outside of vanilla AWS to get a similarly great dev UX. I've used Convox + the Weave ECS AMI on a project, and it was pleasant.
Just getting into Kubernetes :)