Comparing AWS and Google Cloud — An overview
A common question around cloud hosting goes something like this — Aren’t all public cloud offerings more or less the same? Compute Instances, Database and Blob Storage, Similar sounding networking (VPCs) and Security Options (subnets, firewalls) — Isn’t it true that if you know one, you know them all?
While things appear to be similar on the surface, the way each cloud vendor implements these offerings can be significantly different.
Consider a common use case — sudden spikes in your web-app traffic — Are you expecting your cloud’s load balancer to scale seamlessly in the face of increased load?
AWS’s Load Balancer does not scale in real time and is thus, unable to handle sudden spikes (pre-warming provides a workaround). In contrast, Compute Engine’s LB is able to respond to traffic spikes in real time, without requiring any pre-warming.
This is a seemingly minor difference, but for certain web applications, it could be a decisive factor. Several such ‘under the hood’ differences are discussed in this article.
With AWS, one has to jump through a series of networking steps before any resource can be created. These include Picking a VPC, Picking a Subnet, Picking multiple AZs, Assigning an ARN….. These steps go to the heart of the complexity of AWS’ networking constructs.
GCP, in contrast, offers Software Defined Networking.
Utilizing high level constructs called Projects, the only thing you need to specify is a ProjectId for your resources. GCP will figure out the underlying VPC, Subnets etc. for your new resource. Each project essentially gets its own VPC, but if you need to share resources between projects, you do not need to muck with any networking constructs. You can do it at the project level.
It may sound trivial, but the time savings can be significant, as you spin up dozens of instances, containers and what not.
Firewalls, Static IPs and Peering Constructs : GCP uses firewalls as well as IPTables. IPTables are used to block / allow outbound traffic from GCP instances. This is in contrast to AWS which utilizes firewall rules for both outbound and inbound traffic.
Direct Peering — AWS offers direct connect only through third party carriers. Google, since has it’s own underlying fiber option network, allows direct connection to the GCP cloud, in addition to leveraging third party carriers. In effect, GCP has both Carrier based peering and true Direct Peering. AWS only offers Carrier based peering.
Whether this is a must have for your connectivity needs or not, is dependent on your use case: Do you have Terabytes of data being transferred between on-prem instances and cloud instances? If so, you may need Direct Peering and not Carrier based peering.
Users (Cloud Native User Identities)
In AWS, there is a ROOT identity which is managed by AWS. In addition to the root identity, there are several IAM identities (IAM users) with specific roles to access and maintain the variety of AWS resources. These IAM users can be either created directly within AWS or federated from an on-prem AD (or any 3rd party for that matter).
Unlike AWS, GCP’s Cloud IAM does not allow creation of independent identities. It only lets you manage identities created elsewhere (GSuite, Google Groups…). In addition, you can BYOI (bring your own Identity) via ID federation, same as on AWS. Some folks feel this is a cleaner approach, as most of us already have identities on Google, Corporate ADs and elsewhere that we would rather re-use than have to create a fresh new IAM identity.
Is this a win for AWS or Google? Again, it depends on your preference. Do you see the need to create and maintain a new set of user identities on the cloud?
Say you have multiple teams working on the same AWS resources. Or have the need to create separate accounts for the DEV team and the PRODUCTION team. With AWS, the recommendation involves setting up multiple accounts, one for each team (also see — multiple accounts, AWS). This is, as you can see, not scalable and not easily shareable. (Update: With Organizations and OU units now available on AWS, the hierarchical approach is now available on AWS as well).
Google took a hierarchical approach by assuming that certain resources would need to be accessed by multiple parties. Resources go into Projects and Projects go under an Organization. An organization can contain multiple projects. A single account can manage multiple projects. A project can be managed independently or as part of a portfolio (under the same org).
This is a natural approach. If I am building a mobile app backend on the cloud, that’s a project. If I am moving an existing wordpress site to the cloud, that’s another project. If I want data from my wordpress site to be shared by the mobile backend, all I do is make those projects part of the same organization.
An IAM policy applied at the organization level will automatically be inherited by all the projects underneath. No subnetting, No VPC peering or any networking needed to make any of the project resources shareable!
Recently, AWS has also started offering Organizations to share resources between multiple accounts; Using Organizational Units (OUs), one can create a similar resource sharing hierarchy in AWS.
Summary and What’s Next?
Picking a public cloud platform is both — easy and nuanced. While service offerings may look identical on the surface, the subtle differences in the underlying mechanisms, can be a deal breaker (or maker) for your next cloud-hosted app.
- Subscribe to the newsletter on www.anuj.com , for the latest tips on blockchain, cloud computing and containerization technologies.
- Follow Anuj on Twitter.
- Train your internal team to become certified cloud experts, so you never need outside help again. This is one training your development team CANNOT afford to miss — it encompasses real world experience from over 200 migrations.