logo

GCP - Versus

Google Cloud Datastore vs Cloud Firestore vs Firebase Realtime Database

  • Firestore is the successor of Datastore; Datastore is deprecated.
  • Firebase Realtime Database was the original database offering for Firebase.
  • Cloud Firestore, as the name suggests, is a "joint-venture" of Google Cloud and Firebase, it is the new flagship database offering of Firebase.
  • Both Firestore and Realtime Database are NoSQL, using JSON as data format.

Container Registry vs Artifact Registry

Container Registry:

  • GCR is a private Docker registry backed by Cloud Storage.
  • container images only
  • gcr.io

Artifact Registry:

  • a.k.a. GCR v2
  • the recommended service for container image storage and management on Google Cloud.
  • extends the capabilities of Container Registry.
  • support for both container images and non-container artifacts:
    • Container images: Docker, Helm
    • Language packages: Java, Node.js, Python
    • OS packages: Debian, RPM
  • pkg.dev

GKE vs Kubernetes

  • Kubernetes is a piece of software, for container orchestration. You still need to acquire hardware, config and bootstrap the systems, install add-ons, monitor the systems, upgrade to keep the system up-to-date.
  • GKE is a managed service that takes care of those tasks, and you can start utilizing the container orchestration functionality right away.

GKE vs Anthos (GDCV) vs GDCH

  • GKE: all running on GCP.
  • Anthos (GDCV): control plane running on GCP, data plane can be on other clouds (AWS, Azure, etc), VMWare, or Bare Metal. Your cluster needs to be connected to GCP all the time.
  • GDCH: air-gapped, meaning there's no connection to GCP at any time, both control plane and data plane run on customer's hardware (reusing Anthos Bare Metal)

Cloud Run vs Cloud Functions vs App Engine

Google Cloud Platform has several serverless offerings:

  • Cloud Run: for containers, essentially a managed Knative. Launched in 2019.
    • If you worry about "vendor lock-in", Cloud Run is the best choice: code is packaged into standard (Docker) containers; and since Knative is an open source project, you can easily migrate to an on-prem environment or another cloud running Knative, without worrying about hidden differences under the hood.
  • Cloud Functions: Functions as a Service.
    • 1st gen launched in 2016.
    • 2nd gen introduced in 2022, built on top of Cloud Run.
      • Improvements: longer processing time for HTTP functions (up to 60 mins), enabling use cases like data processing pipelines and machine learning; reduces cold starts and latency; increases concurrency to up to 1000 requests per function instance; supports larger instances, up to 16 GB memory and 4 vCPUs.
      • uses Eventarc for event delivery, supporting triggers from different sources.
  • App Engine: Platform as a Service. Launched in 2008, even before "serverless" became a buzzword. Probably not the best choice if you are starting a new development.

Cloud Identity vs IAM vs Identity Platform

  • Cloud Identity: to manage identities of GCP customer's employees, and devices. The identity provider (IdP) for GCP, also the Identity-as-a-Service (IDaaS) solution that powers Google Workspace.
  • Identity Platform: to manage identities of GCP customer's customers.
  • IAM: to manage policies and to apply permissions / roles to those users and groups. Can use an external identity provider (IdP).

GCP API Gateway vs Cloud Endpoint

Both API Gateway and Cloud Endpoint are used to manage your APIs: you create APIs to be hosted on GCP and to be consumed by others.

API Gateway is a relatively new offering.

The key difference:

  • API Gateway: fully managed by Google (based on Envoy)
  • Cloud Enpoint: you need to manage your own. Google just provides a software package called Extensible Service Proxy, or ESP. (ESP v1 based on NGINX and ESP v2 based on Envoy) and you need to deploy it.

Google Cloud API Gateway reduces the complexity of deploying and managing APIs, and it is comparable to Amazon API Gateway and Azure API Management.

Marketplace services vs Managed services

  • Marketplace services: user gets a container and a guide only, need to manage the whole lifecycle on their own; no SLA; no data backup.
  • Managed services: all taken care of by GCP.

Producer Project vs Consumer Project vs Tenant Project

  • Producer Project: A project owned by the API producer team. It can be GCP service or a 3rd party service using Service Infrastructure.
  • Consumer Project: a.k.a. customer project, user project; the project that is used to access a service API.
  • Tenant Project: service producer owned project but contains customer resources. Not visible to consumers directly. A tenant project may be mapped to one or many consumer projects. For example, Cloud SQL is the service, but the underlying resources (like VMs) are provisioned in the tenant project, which are invisible to the customers.

Also there's host project and service projects: in the Shared VPC model, you designate a project as a host project and attach one or more other service projects to it. The VPC networks in the host project are called Shared VPC networks. Eligible resources from service projects can use subnets in the Shared VPC network. The host-project owns the networks in the VPC, which are then used by service projects.

Cloud SQL vs AlloyDB vs Cloud Spanner

There are multiple ways to have a PostgreSQL (compatible) database on Google Cloud Platform:

  • Manual: Install and manage your own PostgreSQL instance on a VM or bare-metal machine.
  • Cloud SQL: running the actual PostgreSQL, Cloud SQL runs database instances on GCE VMs, using PD for storage. Cloud SQL instances run on GCE VMs in a Google-owned project. The customer's database is stored on a GCE PD.
  • AlloyDB: PostgreSQL compatible (i.e. it is NOT PostgreSQL), utilizing Google's infra, better performance and more expensive.
  • Spanner: with PostgreSQL interfact but does not promise 100% compatible.

Note that only manually setup instances and Cloud SQL are running the "real" PostgreSQL; AlloyDB and Spanner are not real PostgreSQL, they are just compatible: AlloyDB is 100% compatible but Spanner is partially compatible.

Spanner provides strong consistency across all regions, whereas AlloyDB is eventually consistent due to the way it handles replication.

AlloyDB is comparable to Amazon Aurora.

Spanner vs Cloud Spanner

Spanner is the internal version and the Cloud Spanner is a service on GCP that can be used by GCP customers.

Under the hood they are using the same db but Cloud Spanner adds a layer that hides some internal features and adds Cloud specific features, so feature wise they are not identical, and neither is a superset.

NCC vs VPC Peering

Network Connectivity Center (NCC) delivers inter-VPC connectivity at 10x the scale of legacy VPC Peering, now supporting up to 250 VPC spokes — with full network isolation and centralized connectivity management model.

VPC peering remains a fundamental and valid way to connect two VPC networks privately. However, its main drawbacks are its non-transitive nature (VPC A cannot talk to VPC C through VPC B) and scaling limitations on the number of peering connections a single VPC can have.

NCC is designed to provide a centralized hub-and-spoke connectivity model. It allows you to connect multiple VPCs and on-premises networks to a central hub, enabling communication between all "spokes" without requiring a full mesh of individual VPC peering connections. This is the recommended solution for organizations that are running into the scaling limits of VPC peering.

Quota Metric Name vs Quota Limit Name

  • Quota metric is like compute.googleapis.com/cpus, which measures CPU usage. Other metric examples:
    • compute.googleapis.com/disks_total_storage: for PD standard.
    • compute.googleapis.com/ssd_total_storage: for PD SSD.
  • Quota limit is like CPUS-per-project-region, which defines the upper limit what you can use. There can be multiple limits for the same metric, e.g. for the CPU metric:
    • CPUS-per-project: Global limit.
    • CPUS-per-project-region: region limit.
    • CPUS-per-project-zone: zone limit.

Workforce Identity Federation vs Workload Identity Federation

Workforce Identity Federation and Workload Identity Federation are both methods of managing identities in Google Cloud, but they cater to different needs.

  • Workforce Identity Federation manages human user access to cloud resources using external identity providers (IdPs)
  • Workload Identity Federation manages application access to cloud resources using external identities.

Essentially, one is for people, and the other is for applications.

serviceAccountUser vs serviceAccountTokenCreator

TL;DR: think of Service Account User as giving a resource the ability to use the service account's identity, while Service Account Token Creator is about a human user or application directly "becoming" the service account to perform actions.

  • roles/iam.serviceAccountUser: allow you to attach a service account to a resource.
    • GCE: the user creating the VM needs the roles/iam.serviceAccountUser role on the specific service account they are assigning to the VM.
  • roles/iam.serviceAccountTokenCreator: This role allows you to impersonate a service account directly from a command-line interface or application.

Constraint vs Organization Policy

TL;DR: a constraint defines the rule, and an organization policy applies the rule.

Imagine you are a city planner creating a building code.

  • Constraint is like a specific rule in the building code. For example, "all new buildings must have fireproof doors." The rule exists, but it doesn't apply to any specific building until you enforce it. The constraint itself is the potential rule.
  • Organization Policy is like a law that says, "All buildings in the Downtown District must follow the fireproof door rule." It's the mechanism you use to apply that specific rule (the constraint) to a set of resources (the buildings in the Downtown District).
logo
PRIVACY POLICYABOUT中文