Google Cloud - For AWS Professionals

Learning a cloud platform takes a long time. Google Cloud and AWS have 200+ services each.

If you are familiar with AWS, this article is the shortcut you need to get quickly started with understanding Google Cloud.

Table of Contents

1. Quick Overview: Google Cloud vs AWS
2. Compute Services
3. Databases
4. IAM - Identity and Access Management
5. Networking
6. Organizing Resources
7. What’s Next?

1. Quick Overview: Google Cloud vs AWS

What is the best way to learn a cloud when you are an expert at a different cloud platform?

I doubt if there is one answer to this question!

All cloud platforms are similar. They have a wide variety of services under different categories: compute, database, networking, storage, security, and machine learning.

We will get started with a quick overview using a Q&A kind of approach. We will look at the question (or context or a problem), the AWS solution, and the comparable Google Cloud solution.

We are taking a 10,000 feet overview. While services are comparable, when you go deeper, you will find significant differences in terms of the details.

1.1: Compute Services

There are a variety of compute services offered by each cloud platform.

If you want complete flexibility to manage OS, software, and hardware used to run your applications, you want to go with the Infrastructure as a Service option. However, with flexibility, you get a lot of responsibility.

• If you want to reduce your responsibilities (concerning scaling, availability, and durability), you might want to use managed services in the cloud.
• If you want to run a simple web application in Google Cloud, you might want to go with either App Engine or Cloud Run (if you want to use containers).
• If you want to implement microservices architecture with Kubernetes, you can go with Google Kubernetes Engine.

Cloud Functions is the serverless, function as a service offering in Google Cloud.

1.2: Database Services

Here is a quick comparison of database services in AWS vs Google Cloud.

1.3: Networking Services

Here is a quick comparison of networking services in AWS vs Google Cloud.

1.4: Storage Services

Here is a quick comparison of storage services in AWS vs Google Cloud.

1.5: DevOps Services

Here is a quick comparison of DevOps services in AWS vs Google Cloud.

1.6: Other Services

Let’s now dig deeper into a few specific important groups of services.

2. Compute Services

Here is a quick comparison of compute services in AWS vs Google Cloud.

Google Compute Engine

• In AWS, we use the EC2 service to provision virtual instances.
• In Google Cloud, the corresponding service is GCE or Google Compute Engine.

To create a VM, you need to choose OS, software (image), and hardware (machine family and machine type). In addition, you can configure firewall rules to restrict inbound and outbound traffic to/from your VM. Persistent Disk is the service to manage block storage attached with Compute Engine VMs.

IP Addresses: Virtual Machines 

Almost all cloud platforms offer solutions to create public, private, and static IP addresses for your resources. In AWS and GCP, the names used to refer to these are different. Other than that, the concepts remain similar.

Managing Virtual Machines

One virtual machine does not provide sufficient scalability and availability for your solution. We need multiple virtual machines. Here are some of the important features that simplify the management of your virtual machines.

Manage Costs for Virtual Machines 

You want to run your VMs at the lowest cost possible. Here are some of the options provided by AWS and Google Cloud to reduce your costs.

App Engine vs AWS Elastic Beanstalk

Google Cloud App Engine and AWS Elastic Beanstalk are the recommended options to run simple web applications and/or REST API.

Here is a comparison of some of the important features of these two services:

3. Databases

Let’s look at the different types of databases in AWS and Google Cloud.

Relational Databases: OLTP - Online Transaction Processing

Let’s start with applications where a large number of users make a large number of small transactions ( small reads and updates). Typical use cases include CRM, e-commerce, and banking applications. The most popular databases are MySQL, Oracle, SQL Server, etc.

Recommended AWS Services in this space is Amazon RDS. Amazon RDS supports Amazon Aurora, PostgreSQL, MySQL, MariaDB (Enhanced MySQL), Oracle Database, and SQL Server. Amazon Aurora provides a “Global Database” option.

Recommended GCP Services are:

• Cloud SQL: Supports PostgreSQL, MySQL, and SQL Server for regional relational databases (up to a few TBs)
• Cloud Spanner: Unlimited scale (multiple PBs) and 99.999% availability for global applications with horizontal scaling

Relational Database: OLAP - Online Analytics Processing

OLAP Applications allow users to analyze petabytes of data. Examples include reporting applications, data warehouses, business intelligence applications, and analytics systems.

• The recommended AWS Managed Service is Amazon Redshift.
• The recommended GCP Managed Service is BigQuery.

NoSQL Databases

NoSQL represents a new approach (actually NOT so new!) to building your databases. NoSQL stands for “not only SQL." You would use NoSQL databases when you need flexible schema: structure data the way your application needs it and you want to let the schema evolve with time.

Most NoSQL databases can scale horizontally to petabytes of data with millions of TPS.

• AWS Managed Services are Amazon DynamoDB and Amazon DocumentDB
• Google Managed Services are Cloud Firestore (Datastore) and Cloud BigTable

Choosing Between Cloud Firestore, Datastore vs Cloud BigTable

Cloud Datastore is managed serverless NoSQL document database. It provides ACID transactions, SQL-like queries, and indexes. It is designed for transactional mobile and web applications.

Firestore is the next version of Datastore with additional capabilities like strong consistency and mobile and web client libraries.

Firestore and Datastore are recommended for small to medium databases (0 to a few Terabytes).

Cloud BigTable, on the other hand, is a managed, scalable NoSQL wide-column database. It is NOT serverless (you need to create instances). BigTable is recommended for data sizes> 10 terabytes to several petabytes. It is usually used for large analytical and operational workloads. BigTable is NOT recommended for transactional workloads. It does NOT support multi-row transactions but supports ONLY single-row transactions.

In-Memory Databases

Retrieving data from memory is much faster than retrieving data from disk. In-memory databases like Redis deliver microsecond latency by storing persistent data in memory.

• Recommended AWS Managed Service is Amazon ElastiCache
• Recommended GCP Managed Service is Memorystoreoth Amazon ElastiCache and Memorystore support Redis and Memcached.

A Quick Summary of Databases

Here is a quick comparison of database services in AWS vs Google Cloud.

4. IAM - Identity and Access Management

Google Cloud and AWS use the same name for their authentication and authorization service: Identity and Access Management (IAM). However, the concepts of IAM are very different.

How Does IAM Work in AWS?

Here are some of the important IAM concepts in AWS:

• IAM users: Users created in an AWS account
  • Have credentials (name/password or access keys)
• IAM groups: Collection of IAM users
• Roles: Temporary identities
  • Does NOT have credentials attached
  • (Advantage) Expire after a set period
  • Use case 1: EC2 talking with S3
  • Use case 2: Cross Account Access
• Policies: Define permissions
  • AWS managed: Standalone policy predefined by AWS
  • Customer managed: Standalone policy created by you
  • Inline: Directly embedded into a user, group, or role

How Does IAM Work in Google Cloud?

IAM in AWS is very different from Google Cloud.

My recommendation: Forget AWS IAM and start FRESH! A role in AWS is NOT the same as a role in Google Cloud.

Let’s take an example: I want to provide access to manage a specific cloud storage bucket to a colleague of mine. Here are some of the important terminology to remember:

In Google Cloud IAM:

• Member: My colleague
• Resource: Specific cloud storage bucket
• Action: Upload/Delete Objects
• Roles: A set of permissions (to perform specific actions on specific resources). Roles do NOT know about members. It is all about permissions!
• Policy: Assign permissions to a member by binding a role to a member

To implement the permissions needed by our example, we need to take two simple steps:

• 1: Choose a role with the right permissions (Ex: Storage Object Admin).
• 2: Create a policy binding member (your friend) with the role (permissions).

A Few More Differences: IAM in GCP vs AWS

Here are a few more important differences:

• IAM in Google Cloud is only responsible for authorization. It does not manage user identity.
• The IAM role is the programmatic identity in AWS. For example, if I want an EC2 instance to be able to talk to an S3 bucket, I will create an IAM role with the right permission and assign it to the EC2 instance. In Google Cloud, the service account is the programmatic identity.

AWS IAM Policy Example

In AWS, a policy is a set of permissions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*", //["s3:Get*","s3:List*"],
            "Resource": "*" //"arn:aws:s3:::mybucket/somefolder/*"
        }
    ]
}

• A policy is a JSON document with one or more permissions:
  • Effect - Allow or Deny
  • Resource - Which resource are you providing access to?
  • Action - What actions are allowed on the resource?
  • Condition - Are there any restrictions on IP address ranges or time intervals?
  • Example above: AWS Managed Policy: AdministratorAccess
  • Give Read Only Access to S3 buckets - "Action": ["s3:Get*","s3:List*"]

Google Cloud IAM Policy: Example

In Google Cloud, Policy is a list of bindings. Each binding binds roles with members.

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
       "members": [
         "user:you@in28minutes.com",
         "serviceAccount:myAppName@appspot.gserviceaccount.com",
         "group:administrators@in28minutes.com",
         "domain:google.com"
       ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:you@in28minutes.com"
      ],
      "condition": {
        "title": "Limited time access",
        "description": "Only upto Feb 2022",
        "expression": "request.time < timestamp('2022-02-01T00:00:00.000Z')",
      }
    }
  ]
}

5. Networking

Let’s now dig deeper into networking concepts.

Networking in AWS: Amazon VPC and Subnets

A VPC(Virtual Private Cloud) in AWS is your own isolated network in the AWS cloud. Network traffic within a VPC is isolated (not visible) from all other Amazon VPCs. You control all the traffic coming in and going outside a VPC.

A subnet separates public resources from private resources in a VPC.

Networking in Google Cloud: VPC and Subnets

VPC and subnets in Google Cloud are very similar to AWS:

• Default VPCs are provided with default subnets.
• You can create your own custom VPCs and subnets.
• You can create different types of resources in different subnets.
• You can use VPC flow logs to debug problems.
• You can set up peering between VPCs to connect different VPCs.
• You can create Shared VPCs to share resources across multiple Google Cloud projects or AWS accounts.

However, it is important to note the differences:

• In AWS, VPCs are regional and subnets belong to an availability zone.
  • However, in Google Cloud VPCs are global and subnets belong to a specific region.
• There are significant differences in default VPCs and subnets configuration.
  • In Google Cloud, default VPCs are created per project.
    • Each default VPC has multiple subnets - one in each region.

6. Organizing Resources

Typically, every enterprise creates thousands of resources in the cloud. Google Cloud and AWS take very different approaches to grouping and managing resources.

Organizing Resources in AWS

Resources in AWS are created in an AWS account. By default, you will be billed per AWS Account.

If you want to create resources for multiple environments, one of the recommended approaches is to create separate AWS accounts:

• Each AWS account provides natural security, access, and billing boundaries.
• Create AWS Organization to organize accounts into Organizational Units (OU)
  • A consolidated bill for AWS accounts
• Use AWS Resource Access Manager to share AWS resources:
  • Share AWS transit gateways, subnets, AWS License Manager configurations, etc.

Organizing Resources in Google Cloud

Google Cloud has a very well-defined hierarchy (Organization > Folder > Project > Resources) to help you organize your resources.

Here are some of the important things to remember:

• Resources are created in projects.
• A folder can contain multiple projects.
• An organization can contain multiple folders.

Here is the recommended approach for managing resources in Google Cloud:

• Create separate projects for different environments. This ensures complete isolation between test and production environments.
• Create separate folders for each department. This will isolate production applications of one department from another. In case you need to share resources, you can create shared folders.
• Recommendation: One project per application per environment

Let’s consider two apps: “A1” and “A2” with two environments each, “DEV” and “PROD." In the ideal world, you will create four projects: A1-DEV, A1-PROD, A2-DEV, and A2-PROD:

• Isolates environments from each other
• DEV changes will NOT break PROD
• Grant all developers complete access (create, delete, deploy) to DEV Projects
• Provide production access to operations teams only!

7. What’s Next?

The next obvious step is to broaden your horizon. I would recommend you to get started with the Google Cloud Free Program, Compare AWS and Azure services to Google Cloud.

A visit to the Cloud Architecture Center can help you discover reference architectures for your workloads on Google Cloud.