Hello, World...

So just a disclaimer on this... none of this will really get you ready for the GCP Certified Architect Exam... It's is really just some decent "Base" information. I just passed, but as much as you need to know, or not know, all of this stuff to various degrees, everything I read, watched, or was trained on: wasn't enough to prepare me for the test.

In a nutshell, you basically need to know all of this and more... and they may never ask you about any of it directly... or they may dive into the exact command line syntax for gsutil or kubectl.

I've also found so much conflicting information contained within Google and other practice exams and even various documentation, that it can be tough to know exactly what the truth is. It's all so hazy. So please take all of this with a grain of salt. But most of all, know how to build out scenarios from all you learn and to forecast into the future

A lot of this is in flight, so it may be outdated by the time I click publish. Heck, some of the material I was learning from was outdated when I got it. Good luck!

And so with that... I'll just be collecting together a boatload of tidbits I learned while studying for the GCP exam:

3 Recommended areas of console focus:

  • IAM (federation, quotas, roles)
  • Compute:
    • App Engine
    • Compute Engine
    • Container Engine
    • Cloud Functions
    • Networking (VPC, VPN, CloudDNS, Routes, Firewall)
  • Storage
    • Bigtable - NoSQL (HBase)
    • Buckets!
    • SQL & Spanner

Other areas where questions popped up (not heavy but know what it is and how it fits together):

  • Deployment manager.
  • Container registry.
  • Endpoints.

Regions and Zones:

  • Region - independent geographic area that contains zones.
  • Zone - deployment area for your resources within a region.
  • Need to protect against a lost of an entire region, or zone.
  • Multi-zone, zone, and region would be the breakdown.
  • Not every product is available in every Americas, Europe, and Asia. Availability
  • Resources are broken down into Zonal, Regional, and Multi-Regional.

IAM Quotas:

  • Unlimited or resources with quotas.
  • Know how to locate and address them.
  • Projects are going to have quotas.
    • Resource quotas limit the number of resources created.
    • Some resources have global and regional quotas.
    • Most can be increased by request.
    • API request quotas limit rate and daily volume.
    • Free quotas allow free use up to limit.
    • Example 5GB cloud storage and 50,000 entity reads.

Hierarchy in GCP:

  • Orgs - a TLD essentially.
    • Can use G-Suite or cloud identity.
    • Link your org domain.
    • Can set access and configs at org or project level.
    • Billing accounts, projects and resources are not deleted when an employee leaves the company.
    • If not using G-Suite this orgs may do you no good.
  • Folders - introduced when you are using cloud IAM (comparable to AWS Directory Services).
    • Assign policies to resources at a granularity of your choosing.
    • Resources in a folder can share IAM policies.
    • Below the Org and above projects categorizations.
  • Projects - pretty much to main interaction point.
    • Resources go here for tracking
    • Billing and accounting is usually tethered here too.
    • Manage permissions and credentials.
    • Enable services and APIs.
    • The main goal is to provide a sandbox.
    • You provide the project name
    • Project ID - GCP provides, usually the AppID.
    • GCP provides the project number.
    • A network can only belong to one project.
    • Default limit of 24 CPUs per project.
    • API's are specific to resources in a given project.
    • They have quotas.
    • Project names must be between 4 and 30 characters.
    • A Project can have up to 5 VPC networks.
  • Resources.

Compute Options (Heavily tested)

Compute Engine: These are VM's that are focused on your enterprise IaaS (Can be linux or windows server)

  • VMs
  • IaaS
  • Templates or custom
  • Cloud Launcher (marketplace)
  • vCPU and memory.
  • Networking
  • OS (Lin/Win)
  • TCP/UDP/IMCP
  • Note: Supports IPv4 only
  • Every VM instance belongs to a network.
  • Storage:
    • Standard (zonal persistent)
    • SSD (zonal persistent)
    • Local SSD
    • Can resize or migrate with no downtime.
  • If in the same network, they can communicate on the local lan.
  • If wanting to connect to the internet, we'll need to provision external IPs.
  • Global, Regional, & Zonal resources
    • Global resources include pre-configured disk images, disk snapshots, and networks.
    • Regional resources include static external IP addresses.
    • Zonal resources include VM instances their types and disks.
  • Compute engine VM comes with a single root persistent disk
  • Image is loaded onto root disk during the boot process.
    • Bootable - you can attach to a VM and boot from it.
    • Snapshots - incremental backups.
    • Durable - can survive VM terminate
    • Some SW is installed and the OS is configured by GCE
  • Each persistent disk can be up to 64TB in size.
  • Each instance can attach only a limited amount of total persistent disk space and a limited number of persistent disks.
  • A single FS gives the best perf on a persistent disk.
  • Local SSDs = high IOPS and low latency.
  • You don't really need to know the speeds... but know the use cases... if you are using a local SSD, know why... persistent disk, know zonal and regional. etc.
  • Migrating VMs:
    • Manual & Automatic
    • Don't use on a VM with a local SSD
    • The local SSD data cannot be backed up and will just be discarded.
    • Persistent disks have to be attached to only the VM you are going to move (multiples are not supported)
    • Sufficient quota must exist for all the resources copied during duplication, or the process will fail.
  • Snapshots:
    • Snapshot is not available for local SSD
    • Creates an incremental backup to GCS
    • Snapshots can be restored to a new persistent disk
    • Don't use for database migration across zones
    • Cannot be shared across projects.
  • VM access - CLI linux - need FW rule port 22
    • SSH (from console, CloudShell SDK, or computer.
    • gcloud compute ssh (instance name)
  • VM access - windows RDP - need FW rule port 3389.
    • poweshell pssession
    • gcloud compute ssh (instance name)
  • Auto restart of VM. - what the VM should do after a hardware failure or system event. If marked, it will try and launch a replacement VM. Auto-restart does not automatically restart the VM if terminated due to a user event (shutdown or termination)
    • Note: if the VM availability policy is set to the default, live migrate, during regular system maint, your VM will be migrated to diff hardware so there is not downtime.
  • Creating VM's - items to consider:
    • Each zone supports a combination of processor generations.
    • Creating an instance in a zone, your instance will use the default processor supported in that zone. Some support GPU, some TPU, etc.
      • ex: us-central1-a (Iowa) will have Sandy Bridge.
  • Instance Groups:
    • uses an instance template to create or update the instances that are part of the group.
    • Create template once and reuse it for multiple groups and configs.
    • Template is global, and not bound to zone or region.
    • You can specify a zonal resource in a template tho, and this will restrict it.
    • By default, instances from the group will be placed in the Default and and randomly assign IPs from the Regional Range.
    • Three types: Managed Regional, Managed Zonal, and Unmanaged
      • Unmanaged: dissimilar instances that you can arbitrarily add/remove from the group. These do not offer autoscaling, rolling updates, or use instance templates. Only use these if you have dissimilar types of instances or if you need load balancing to pre-existing configurations. Will support Linux variants and Win versions
      • Managed groups are the recommendation.
  • Migrating VM's to GCP:
    • Importing virtual disks - use the import tool. It supports most formats VMDK, VHD, and RAW. This is going to use CloudBuild: this is used to help deploy infra. Also a pre-check tool for incompatibilities.
    • Velostrata - Agentless cloud migration and the service is free to use for customers migrating into GCP from another cloud service.
    • CloudEndure - agent based managed service which supports on-prem-to-cloud and cloud-to-cloud migrations.
  • Know the billing approaches and the tools:
    • Bill per second, min of one min.
    • Preemptable (24hrs) - kinda like spot.
    • Discounts - Committed use - kinda like reserved. The more it's used, the more you save. They don't want them just sitting idle.
    • Savings - up to 80% and no prepaid contract.
    • Inferred instance - for billing purposes, the same type of machine used in the same zone will be combined into a single charge.
  • You will get recommendations for optimizing (rightsizing) VMs. These are generated automatically.

App Engine: PaaS - two different environments: Standard or Flexible. Mobile apps fit good here.

  • PaaS
  • Fully managed, just worry about your code
  • Supports code written in supported langs:
    • Python
    • Java
    • Node.js
    • Go
    • Ruby
    • PHP
    • .Net
  • Standard or Flexible Environments.
  • SDK kits so that you can dev locally.
  • App Engine is Regional
    • Google will manage it redundantly across all zones in that region.
    • You cannot change a region after you set it.
  • Free and paid resources available.
  • Supports the Spring Framework and MemCache
  • Support and SLA
  • Supports:
    • Traffic splitting
    • Application versioning
    • Integrates with StackDriver
  • Heavily tested and meant for you to deploy your web applications.
  • Instances are health-checked and healed as necessary, and co-located with other services within the project.
  • Critical, backwards compatible updates are automatically appled to the underlying operating system.
  • VM instances are automatically located by geographical region according to the settings in your project.
  • VM instances are restarted on a weekly basis and GCP will apply any necessary operating system and security updates.
  • Root access to ComputeEngine VM instances.
  • SSH to VM instances in the flex env is disabled by default.
  • Should I use Standard or Flexible:
    • Standard: means that your app instances run in a sandbox, using the runtime env pf a supported lang.
    • Flex: means that your app instances run within Docker containers on GCE VM's.
    • It adds the ability to pick Ruby or .Net as well as pick any version of the langs that you choose.
  • Cloud Security Scanner: a cool feature that can help you find security problems in your app so that you can head off potential attacks.
  • Ways to store your data in AppEngine:
    • Cloud DataStore for NoSQL / Schemaless.
    • Cloud Storage for files and metadata
    • Cloud SQL for relational db data such as MySQL/PGSQL
    • Connect 3rd party: Redis, Mongo, Cassandra, Hadoop
  • Scaling:
    • App.yaml controls type and instance class (resources)
    • 3 Types (depends on the instance class):
    • manual
    • basic
    • automatic
  • App Engine A/B Testing
    • Traffic splitting
    • specify eprcentage distribution across 2 or more versions within a service
    • control the pace of the rollout
    • splitting is applied to URLs that do not explicitly target a version
    • NOTE: Required privs and check caching issues
  • 3 different approaches to splitting traffic:
    • IP address
    • Cookie
    • Random
  • Traffic migration depends on environment
    • Standard: you can choose the route requests to the target version either immediately or gradually. Cannot expose these machines to the world.
    • Flexible: Gradual migrations are not supported - can also attach ephemeral disks. Can expose these machines to the world.
    • Note: warm-up requests improve user response time by allowing the version currently receiving traffic to handle those requests.
  • Traffic migration or traffic splitting???
    • They will try and get you on this!
    • Traffic migration switches the request routing between the versions within a service. Essentially moving traffic from one or more versions to a single new version.
    • Traffic splitting is between two or more versions of your application for A/B testing. Traffic splitting is applied to URLs that do not explicitly target a version.
  • Each instance has an initial start up cost of 15 minutes
  • Note which case study uses this. Be aware if they locate other GCP services in other regions that this can depend on.
  • Contains Blobstore, but recommends Google Cloud Storage
  • Shared or dedicated Memcache
  • Can set up custom domains or register them here too. Upload certs as well.

Kubernetes Engine - container management. May be a good fit for CI/CD build pipeline with containers.

  • The amount of content here has increased.
  • Manage applications, not machines.
  • Why Use?
    • Workload portability
    • Run in many envs, across cloud providers
    • Implementation is open and modular
    • Rolling updates:
    • Upgrade application with zero downtime
    • Autoscaling
    • Automatically adapt to changes in workload
  • Terms
    • Pod - hosts containers.
    • Volume - any data access mounted to a pod. Can persist. Are available to all containers in a pod.
    • Container - if > 1 per pod, they are guaranteed to be scheduled together on the same VM
    • Cluster - Containers package an application so it can be easily deployed to run in its own isolated environment. Containers are managed in clusters that automate VM creation and maintenance. A Kubernetes cluster is a managed group of VM instances for running containerized applications.
    • Pools - instance groups in a kubernetes cluster
    • All VM's in a pool are the same
    • Pools can contain different VMs from one another
    • Pools can be in different zones GKE is node pool aware
    • Labels on VMs in the pool make them available to GKE
    • Node pools and Multi-zone container clusters
      • Node pools are separate instance groups running Kubernetes in a cluster. You may add node pools in different zones for higher availability, or add node pools of different type machines.
    • GKE will replicate all the pools along with all the clusters.
      • Be careful, this could use up quotas in the region.
    • Workloads - what runs inside of the container cluster.
    • Applications - Can deploy from the marketplace. Kubernetes Applications collect containers, services and configuration that are managed together.
    • Services - Service instances are applications that your Kubernetes application can connect to and use. In order to work with service instances, you have to install service catalog on your cluster first.
Kubernetes Engine App Engine Std App Engine Flex
Language Any Java, Python, Go, PHP. Node Any
Service Model Hybrid PaaS PaaS
Use Case Containers Web & Mobile Web & Mobile container based

source: dev.to