Anuj has been the lead architect on over a dozen large scale migrations for a variety of application portfolios.

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?

My response, after 10 years of working with all three cloud platforms, is a decisive ‘No’. 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.

Networking Nuances

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. 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 lots and lots of data being transferred between on-prem instances and cloud instances?

Resource Management Nuances

This is one of those areas where GCP’s flexibility clearly wins. 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.

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! To me, this is a huge time saver. Recently, AWS has also started offering Organizations to share resources between multiple accounts; however, the GCP hierarchy (which also includes Folders, is more powerful)

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?

Compute (IaaS) Nuances

Machine Images

• AWS lets you store images on EBS volumes or S3 buckets. GCP stores them directly on compute instances.
• AWS offers a community repository of images; GCP does not.

This is a clear win for AWS.

Instance Migrations — No ‘live’ migration possible in AWS (only snapshot based migrations). GCP offers a feature called live migration, which transparently migrates instances from on-prem to GCP. This is a clear win for GCP; although with certain 3rd party tools, a similar migration could be accomplished on AWS.

A/B Testing

When I took my Google professional certification exam, I was surprised at the number of questions around application deployment and testing scenarios.

Deploying an app means creating a configuration file and deploying the binaries using either the Console or the CLI. This is true in both GCP and AWS. However, in GCP, there is no downtime when deploying a new version of a running app.

Call me an app guy, but most folks are using the cloud to host their mission critical applications (yes, some are using it for cheap storage as well :). In the long run, the headaches around deploying new versions of production applications cannot be overstated. For me, GCP offers a cleaner, native solution to deploying parallel versions of production apps, entailing zero downtime to going live with your new release!

Containers / CaaS / FaaS

The differences in Container support is so significant, it deserves an article of it’s own.

Scheduling of tasks and Service Discovery are key components that are not only easier in GCP, but offer a ‘pluggable’ architecture.

Functions as a service (FaaS) work similarly in both platforms, though there are again differences, worthy of their own blog post.

Summary

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. Got a burning cloud question? Set up a 15 minute free call with Anuj Varma.