--> Cymbal Superstore's Resource Hierarchy

Organization Level - Cymbal Superstore

|
|
Folder Level - Operations Sales and Marketing
Logistics
| | |
B2B Supply Chain ECommerce App
Transportation App
App
|
Project Level B2B Dev B2B Staging B2B Production

--> Cymbal Superstore's Identity and Access Roles

Who - Data Analyst

Can do what View data and Run queries
On which resource - BigQuery Datasets

===================================================================================
=========================================================================

--> Online Application Challenges before cloud

Peak usage during holidays and weekends

Less Load during rest of the time

So during the peak the company had to do "PEAK LOAD Provisioning" which means to
"Procure"(Buy) infrastructure "for peak load"
Note: Once bought the infrastructure would be doing nothing during periods of low
loads and you would be paying for it

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------
--> Imagine Another scenario where a startup becomes popular

So in this we need to handle the sudden increase in load.

The solution is to Procure infrastructure assuming they would be successful
But what if they fail ? You will be paying for the whole infrastructure without
using it to its fullest and is wasted

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> What were the challenges

High cost of procuring infrastructure

Needs ahead of time planning(Can you guess the future?)
Low infrastructure utilization(PEAK LOAD provisioning)
Dedicated infrastructure maintenance team(Can a startup afford it?)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Silver Lining in the cloud

How about provisioning(renting) resources when you want them and releasing them
back when you do not need them?
Also called on-demand resource provisioning
Also called "Elasticity"

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> What are the advantages

You only pay for what you use

Since there are many providers you can take advantage of that fact
You do not have to guess capacity as you can increase/decrease as you need
You do not have to waste money for maintaining data centers
You can launch your application in global level i.e., outside of your region
anytime

===================================================================================
=========================================================================
-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Google Cloud

Services

1. Google Compute
Engine(GCE)

In corporate data centres, applications are deployed to physical servers

Where do you deploy applications in the cloud ?
Rent Virtual Servers
Virtual Machines - Virtual Servers
Google Compute Engine(GCE) - Provision and Manage Virtual Machines

- Features(GCE)

Create and manage lifecycle of virtual machine(VM) instances i.e., start, restart,
stop...
Load Balancing and Auto Scaling for multiple VM instances
Attach Storage(& Network Storage) to your VM instances
Manage network connectivity and configuration for your VM instances

- What is the Goal

Setup VM instances as HTTP(web) Server

Distribute load with Load Balancers

--> Compute Engine Hands-On

- What we will doing

Create few VM instances and perform tasks

Checkout the Lifecycle of VM instances
SSH to connect to VM instances

- Machine Family

General-Purpose
Compute-Optimized
Memory-Optimized
GPU

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Static IP Address

Note: An external IP address get reset after stopping and starting a server

Scenario: How do you get a constant External IP address for a VM instance

Search for "External IP Address" in VPC section >> click on "Reserve Static
Address" and enter the details >> Click on "change" in the same row and assign a
VM instance to the external IP

Static IP "can be switched" to another VM instance in same project

Static IP "remains attached" even if you stop the instance. You have to manually
detach it

Note: You are "billed for" an static IP when "you are NOT using it"
Make sure that you explicitly release an static IP when you are not using it

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Simplify VM HTTP server setup

Executing these steps manually requires a lot of steps and time. So how do we
reduce the number of steps in creating an VM instance and setting up a HTTP server?

Here are few options,

Startup Script
Instance Template
Custom Image

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

A. Startup Script

- Bootstrapping with startup script

"Bootstrapping: Installing OS patches or software when an VM instance is launched.

In VM, you can configure "Startup Script" to bootstrap

Create VM instance >> Under "Firewall", click on "Management" >> Under "Management"
there is "Startup script" under "Automation" >> Paste your script and click on
launch

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

B. Instance Template

- Why do we need to specify all the VM instance details(Image, instance type etc)
every time you launch an instance?
How about creating an instance template ?
 Define machine type, image, labels, startup script and other properties

- Used to create VM instances and managed instance groups(MIG)

provides a convenient way to create similar instances

- "CANNOT" be updated
to make a change, copy an existing template and modify it

- (Optional) Image family can be specified(example debian-9):

latest non-deprecated version of the family is used

- Demo Launch VM instances using Instances templates

Virtual Machines >> Instance Templates >> Paste the script you want >> Three dots
on the same row >> click on create VM instance

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

C. Reducing Launch Time with Custom Image

- Installing OS patches and software at launch of VM instances "increases boot up

time"
- How about creating a custom image with OS patches and software pre-installed?
Can be created from an instance, a persistent disk, a snapshot, another image, or
a file in cloud storage
Can be shared across projects
(Recommendation) Hardening an image - Customize images to your corporate security
standards
- Prefer using "Custom Image" to "Startup Script"
- DEMO: Create a Custom Image and using it in an Instance Template

Click on "Storage" >> Go to "Disks", a disk will be shown attached to your VM

instance >> Next click on the three dots and "create image". Fill in the fields as
per your needs >> "Create"

Note: To create an image the VM instance "shouldn't be running"

Now, Create "VM instance" >> in boot disk select "custom image" >> create.

Note: You can now create instances by clicking the three dots

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================

Discounts

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> 1. Sustained Use Discounts

- Automatic Discounts for running VM instances for significant portion of the
billing month/
Example: If you use N1, N2 machine types for more than 25% of a month, you get a
20% to 50% discount on every incremental minute
Discounts increases with usage(more the usage more the discount i.e., if a
machine is used for 80% then you can expect a discount of 25%)
No action required from our side

- Applicable for instances created by "GKE and GCE"

- RESTRICTION: Does not apply on certain machine types(example:E2 and A2)

- RESTRICTION: Does not apply to VMs created by App Engine flexible and Dataflow

Note: Discount that is automatically applied

--> 2. Committed Based Discounts

- For workloads with predictable resource needs

- Commit for 1 year or 3 years
- Up to 70% discount based on machine type and GPUs
- Applicable for instances created by "GKE and GCE"
- RESTRICTION: Does NOT apply to VMs created by App Engine flexible and Dataflow

- DEMO: How to purchase committed use discounts

Virtual Machine >> Committed Use Discounts >> Purchase Commitment >> Enter the
details and purchase

NOTE: Be careful before committing

--> 3. Preemptible VM

- Short-lived, cheaper(up-to 80%) compute instances

Can be stopped by GCP any time(preempted) within 24 hours
Instances get 30 seconds warning(to save anything they want to save)

- Use Preempt VM's if:

Your applications are fault-tolerant
You are very cost-sensitive
Your workload is NOT immediate
Example: Non-immediate batch processing jobs

- RESTRICTIONS:
NOT always available
NO SLA and CANNOT be migrated to regular VMs
NO Automatic Restarts
Free Tier credits not applicable

- DEMO: How to create a Preemptible VM

VM Machine >> VM instance >> Create VM >> Under Firewall, there are other
options(Management, Security...) >> Under "Management" click on "Pre-emptibility"

- Some other pointers

After 24 hours, the PVMs are permanently terminated but you can use the
persistent disk attached to it on another VM and the data stored in that can be
accessed.
The data in Ephiphermal(Temporary) storage are erased if the PVMs are terminated

NOTE: You can write a script such that if a VM is getting preempted, it can
automatically save it's data on the persistent disk

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================

Billing

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> GCE - Billing

- You are "billed by the second"(after a minimum of 1 minute)

- You are NOT billed for compute when a compute instance is stopped
However, you will be billed for any storage attached to it
- (RECOMMENDATION) "Always create Budget alerts" and make use of Budget exports to
stay on top of billing.

- What are the ways you can save money?

Choose the right machine type and image for your workload
Be aware of discounts available
Sustained use discounts
Committed use discounts
Discounts for preemptible VM instance

- DEMO: How to create a Budget

Billing >> Budgets and Alerts >> Create Budget >> Enter your specified budget, set
thresholds notifications....

- DEMO: How to export bill

Billing >> Billing Export >> You can now either export it as a file or export it to
Big-Query where you can run searches

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================

Live Migration and

Availability
-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Compute Engine: Live Migration and Availability Policy

- How do you keep your VM instances running when a host system needs to be
updated(a software or a hardware update needs to be performed)?
When there is a update from GCP on your instance and in case if it is running, it
will be terminated.

- (SOLUTION) Live Migration

Your running instance is migrated to another host in the same zone
Does NOT change any attributes or properties of the VM
SUPPORTED for instances with local SSDs
NOT SUPPORTED for "GPUs" and "PVMs(preemptible instances)"

- Important Configuration - "Availability Policy"

On host maintenance: What should happen during periodic infrastructure
maintenance?
Migrate(default): Migrate VM instances to other hardware
Terminate: Stop the VM instance

Automatic Restart - Restart VM instances if they are terminated due to non-user-

initiated reasons(maintenance event, hardware failure etc.)

- DEMO: How to enable live migration

VM Machine >> New VM instance >> Under firewall, Management, security, disks... >>
Under "Management" >> "On Host maintenance"(Migrate VM instance automatically
enabled) / "Automatic Restart"("On" default)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Compute Engine Features:

--> 1. Custom Machine Types

- What do you do when predefined VM options are NOT appropriate for your workload
Create a machine type customized to your needs(a Custom Machine Type)

- Custom Machine Type: Adjust VCPUs, memory, and GPUs

Choose between E2, N2, or N1 machine types
Supports a wide variety of Operating Systems: CentOS, CoreOS, Debian, Red Hat,
Ubuntu, Windows etc

NOTE: Billed per VCPUs, memory provisioned to each instance

Example Hourly Price: $0.033174/VCPU + $0.004446/GB

- DEMO: Configure a custom machine type

Create VM machine >> VM instance >> Machine Family >> Machine Type >> Custom
Machine >> Set the Cores and Size accordingly

--> 2. GPU - Graphic Processing Unit

- How do you accelerate math intensive and graphic-intensive workloads for AI/ML
etc?
- Add a GPU to your virtual machine:
High performance for math intensive and graphics intensive workloads
Higher cost
(REMEMBER) Use images with GPU libraries for (deep learning) installed
(OTHERWISE, GPU will not be used)

- GPU restrictions:
NOT Supported on all machine types(For example, not supported on shared-core or
memory-optimized machine types)
On host maintenance can only have the value "Terminate VM instance"

NOTE: There is no option for "Live Migration".

- Recommended Availability policy for GPUs

Automatic restart - On

Demo - Configuring a GPU

1. Choose GPU in the machine family(A2 and N1 only)

2. You can choose any other machine family and you can add GPU(applicable only for
A2 and N1)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

---> Points to Remember

- Virtual machine is associated with a project

- Machine Type availability can vary from region to region

- You can only change machine type( adjust the number of vCPU and memory) of a
stopped instance
You CANNOT change the machine type of a running instance

- VM's can be filtered by various properties

Name, Zone, Machine Type, Internal/External IP, Network, Labels

- Instances are Zonal(Run in a specific zone(in a specific region))

NOTE: Images are global(You can provide access to other projects - if needed)
Instance templates are global (Unless you use zonal resources in your templates)

- Automatic Basic Monitoring is enabled

Default Metrics: CPU Utilization, Network Bytes (in/out), Disk Throughput/IOPS
For memory Utilization and Disk space Utilization, Cloud Monitoring agent is
needed)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

Virtual Machine - Best Practices

- Choose Zone and Region based on:

Cost, Regulations, Availability Needs, Latency and Specific Hardware needs
Distribute instances in multiple zones and regions for high availability

- Choose right machine type for your needs:

 Play with them to find out the right machine type
Use GPUs for Math and Graphic intensive applications

- Reserve for "Committed use discounts for constant workloads

- Use preemptible instances for, fault-tolerant, NON time critical workloads

- Use "labels" to indicate environment, team, business unit etc

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Virtual Machine: Compute Engine Scenarios

- 1. What are the pre-requisites to be able to create a VM instance ?

SOLUTION: Project
Billing Account
Compute Engine APIs should be enabled(Remember to enable the Compute
Engine API when you create a new project) Disabled in default.

- 2. You want dedicated hardware for your compliance, licensing, and management
need

- Usually the VM instance launched is in a shared model/public cloud

- The solution is to use "Sole Tenant" models.

- How to setup:

Virtual Machine >> Sole Tenant nodes >> Create Node group >> Name, Region,
template(existing/create) >> Create

Virtual Machine >> Virtual instance >> Create VM >> Scroll down to Management,
Security, Disks, Sole Tenants >> Sole Tenancy >> Enter the Affinity Labels

NOTE: Keep a note on Affinity Labels while creating a node template with which can
group nodes.

3. I have 1000s of VM and I want to automate OS patch management, OS inventory

management and OS configuration management(manage software installed)

VM Manager > OS patch Management >> Enable VM manager

4. You want to login to your VM instance to install software

- You can SSH into it

- Do not assign an external IP Address

5. You want to allow HTTP traffic to your VM

- Configure Firewall rules

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------
===================================================================================
=========================================================================

---> 2. Gcloud

- Command line interface to interact with Google Cloud resources

- Most GCP services can be managed from CLI using Gcloud

Compute Engine Virtual Machine
Managed Instance Groups
Databases
and .. many more

- You can create/delete/update/Read existing resources and perform actions like

deployments as well

- (REMEMBER) Some GCP services have specific CLI tools:

Cloud Storage - gsutil
Cloud BigQuery - bq
Cloud Bigtable - cbt
Kubernetes - kubectl(In addition to Gcloud which is used to manage clusters)

- Installation

Gcloud is part of Google Cloud SDK

Cloud SDK requires python

You can also use Gcloud from cloud shell(Pre-built in Google Console)

- "gcloud init" - Command to initialize or reinitialize gcloud

Authorize gcloud to use your user account credentials
Setup Configurations
Includes current project, default zone etc

- "gcloud config list" - lists all properties of the active configuration

- "gcloud config list account" - Lists the account name

- "gcloud config list compute region" - Lists region

- "gcloud config list core/account" - Lists the account

- Get more details with "gcloud config list --help"

--> Gcloud config set

- Sets the specified property in your active configuration

"gcloud config set core/project VALUE"

"gcloud config set compute/region VALUE"

"gcloud config set compute/zone VALUE"

"gcloud config set core/verbosity VALUE(debug)"

- Syntax - gcloud config set SECTION/PROPERTY VALUE

 core, compute - SECTIONS
project, region, zone - PROPERTIES

Specifying core is "optional" as it is default SECTION!

"cloud config set project "VALUE"
gcloud config set verbosity VALUE(debug)

- Get more details with "gcloud config set --help"

NOTE: Enter ":q" to come out

- Opposite: "gcloud config unset"

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Gcloud - Managing Multiple Configurations

Scenario: You are working on multiple projects from the same machine. You would
want to be able to execute commands using different configurations

How do simplify this?

"gcloud config configurations
create/delete/describe/activate/list"

- "gcloud config configurations list" - lists all the configurations

- "gcloud config configurations create NAME" - creates a configuration and

activates it

- "gcloud config configurations activate CONFIGURATION NAME" - Activates the

provided configuration

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Google Command Structure - Playing with Services

--> gcloud GROUP SUBGROUP ACTION ......

GROUP - config or compute or container or dataflow or functions or IAM or ...

which service group are you playing with

SUBGROUP - instances or images or instance-templates or machine-types or

regions or zones
which sub group of the service do you want to play with

ACTION - create or list or start or stop or describe or ......

what do you want to do ?

- EXAMPLES:

gcloud compute instance list

gcloud compute zones list
gcloud compute regions list
gcloud compute machine-types list
 gcloud compute machine-types list --filter="zone:us-central1-b"
gcloud compute machine-types list --filter="zone:(us-central1-b europe-west1-d)"

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> gcloud compute instances - in-depth

- Creating compute instances

- "gcloud compute instances create [NAME]"

- Options

--machine-type(default type is n1-standard-1)(gcloud compute machine-types

list)
--custom-cpu --custom-memory --custom-vm-type(n1/n2)(Custom Machine)
--custom-cpu 6 --custom-memory 3072MB --custom-vm-type n2
--image or --image-family or --source-snapshot or --source-instance-template
or --source-machine-image(beta)
--service-account or --no-service-account
--zone=us-central1-b
--tags(List of tags - Allow network firewall and routes to be applied to the
VM instances
--preemptible
--restart-on-failure(default) --no-restart-on-failure --maintenance-
policy(MIGRATE(default)/TERMINATE)
--boot-disk-size, --boot disk-type --boot-disk-auto-delete(default) --no-
boot-disk-auto-delete
--deletion-protection --no-deletion-protection(default)
--metadata/metadata-from-file startup-script/startup-script-url
--metadata-from-file startup-script=/local/path/to/the/script/startup
OR --metadata-startup-script="echo 'hello world'"
shutdown script
--network --subnet --network-tier(PREMIUM(default), STANDARD)
--accelerator="type=nvidia-tesla-v100,count=8" --metadata="install-nvidia-
driver=True" (GPU)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Compute Instances - Default Region and Zone

- There are three options to set a default Region/Zone

- Option 1(Centralized Configuration): gcloud compute project-info add-metadata

--metadata=[google-compute-default-region=REGION | google-compute-default-
zone=ZONE]
- Option 2(Local gcloud configuration): gcloud config set compute/region REGION,
gcloud config set compute/zone ZONE
- Option 3(Command Specific): --zone or --region in the command

NOTE: Additional Option using the console: Compute >> Virtual Machine >> Settings
>> Settings >> Region/Zone

NOTE: Priority Option 3(if exists) overrides Option 2(if exists) overrides Option 1
-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> List and Describe Commands

- Typically list commands are used to list a set of resources

- gcloud compute RESOURCES list
gcloud compute images/regions/zones/disk-types list
gcloud compute instances/disks/snapshots list

- Most list commands support a few common options

--filter="zone:VALUE"
--sort-by (NAME, ~NAME)
--uri
gcloud compute images list --sort-by NAME --filter "PROJECT (windows-cloud
ubuntu-os-cloud)"

- Typically describe commands are used to describe a specific resource

gcloud compute images describe ubuntu-1604-xenial-v20210203 --project ubuntu-os-
cloud
gcloud compute regions describe us-central1

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

---> Playing with Compute Instances - gcloud

- Playing with compute instances

- gcloud compute instances list/start/stop/delete/reset/describe/move

"gcloud compute instance start example-instance"

"gcloud compute instance stop example-instance-1 example-instance-2"
"gcloud compute instances delete example-instance"
--delete-disks=VALUE(all or data or boot)
--keep-disks=VALUE(all or data or boot)

NOTE: The "move" command has been deprecated

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Playing with instance template

- gcloud compute instance-templates create/delete/describe/list

- "gcloud compute instance-templates create INSTANCE-TEMPLATE"
--source-instance=SOURCE_INSTANCE --source-instance-zone(which zone to create
a template from?)

- Supports almost all options supported by "gcloud instance create [NAME]"

--image or --image-family or --source-snapshot or --source-instance-template
--service-account or --no-service-account
--tags
--preemptible
--restart-on-failure(default) --no-restart-on-failure --maintenance-
policy(MIGRATE(default)/TERMINATE)
--boot-disk-size, --boot-disk-type --boot-disk-auto-delete(default) --no-boot-
disk-auto-delete
--deletion-protection --no-deletion-protection(Default)
--metadata/metadata-from-file startup-script/startup-script-url
--network --subnet --network-tier (PREMIUM(default), STANDARD)
--accelerator="type=nvidia-tesla-v100,count=8" --metadata="install-nvidia-
driver=True"(GPU)

- Using instance template to create an instance

gcloud compute instances create my-test-vm --source [NAME of the instance]

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================

3. Instance Groups

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Instance Group

- How to create a group of VM instances

- Instance Group - Group of VM instances managed as a single entity
Manage group of similar VMs having similar lifecycles as ONE
UNIT

- Two Types of Instance Groups

- i. Managed: Identical VMs created using a template:
Features: Auto scaling, Auto Healing, and Other Services

- ii. Unmanaged: Different configuration for VM in same group:

Does NOT offer auto scaling, auto healing, and other services
NOT recommended unless you need different kinds of VMs

- Location can be ZONAL or REGIONAL

- Regional gives you higher availability(RECOMMENDED)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> A. Managed Instance Groups - MIG

- Managed Instance Group - Identical VMs created using an "instance template"

- Important Features:
Maintain certain number of instances
If an instance crashes, MIG launches another instance

Detect application failures using health check (Self Healing)

 Increase and Decrease instances based on load (Auto Scaling)

Add "Load Balancer" to distribute load

Create instances in multiple zones(Regional MIGs)

NOTE: Regional MIGs provide higher availability compared to zonal MIGs

Release new application versions without downtime

i. Rolling Updates: Release new version step by step(gradually).
Update a percentage of instances to the new version at a time
ii. Canary Deployment: Test a new version with a group of instances
before releasing it across all instance.

--> Creating Managed Instance Group(MIG)

- Instance Template is Mandatory *

- Configure auto-scaling to automatically adjust number of instances based on load:

Minimum number of instances

Maximum number of instances

Autoscaling metrics: CPU utilization target, Load Balancer Utilization

target or Any other metric from Stack Driver
Cool-down period: How long to wait before looking at
auto scaling metrics again
Scale in Controls: Prevent a sudden drop in number of
VM instances
Example: Do not scale in by more
than 10% or 3 instances in 5 minutes

Auto healing: Configure a Health check with initial delay (How long should
you wait for your app to initialize before running a health check?)

--> Demo

>> Virtual Machine >> Instance template >> Make sure a instance template exists >>
Instance Groups >> instance groups >> create instance group

NOTE: If you are grouping the existing instances then it might be "Unmanaged
Instance Group"
If you create a group of instances based on instance template then you are creating
a "MIG"

NOTE: There are again two types in MIGs, they are stateless and stateful
Stateful - If you need to create a database and does not want to loose any
instances

Create >> Enter the group name >> Fill in the details like instance template, Auto
scaling factors, No of VMs for auto scaling, health check....

NOTE: You can click the instance group to explore the remaining
factors/configurations. You can also edit the group i.e., health matrix, instances
count,
 scaling

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Updating a Managed Instance Group(MIG)

- Rolling Update: Gradual update of instances in an instance group to the new

instance template
Specify new template:
(OPTIONAL) Specify a new template for "canary testing"

NOTE: In rolling you update set of instances i.e., say if you have ten instances,
you update two instances first, then again two and so on.

NOTE: Canary Testing is where you configure a canary template, test it out on set
of instance say two and then update the remaining instances

Specify how you want the update to be done:

When should the update happen?
Start the update immediately(Proactive(default)) or when
instance group is resized later(opportunistic)

How should the update happen?

Maximum Surge: How many instances are added at any point in time?
Maximum unavailable: How many instances can be offline during the
update?

- Rolling Restart/Replace: Gradual restart or replace of all instances in the group

No changes in template BUT replace/restart the existing VMs
Configure Maximum surge, Maximum unavailable and what you want to
do(Restart/Replace)

--> Demo:

Virtual Machine >> Instance Group >> Select a MIG >> update VMs >> Select new
template, Select if you want canary testing or not >> Select update type

Restart/Replace >> Select the number of instances that you want to make
unavailable(Max-unavailable) or temporary additional instances(Max-surge)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Instance Group Scenarios

A. You want MIG managed application to survive zonal failures

Create multiple zone MIG(or regional MIG)

B. You want to create VMs of different configurations in the same group

Create Un-managed Instance Group

C. You want to preserve VM state in an MIG

Stateful MIG preserve VM state(Instance name, attached persistent disks and

Metadata). Recommended for stateful workloads(database, data processing apps)

D. You want high availability in an MIG even when there are hardware/software
updates

Use an instance template with availability policy automatic restart: enabled and
on-host maintenance: migrate. Ensures live migration and automatic restarts.

E. You want unhealthy instances to be automatically replaced

Configure health check on the MIG(Self-Healing)

F. Avoid frequent scale up and down

Cool-down period/Initial delay

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Playing with Managed Instance Groups - Basics of using Google CLI

- "gcloud compute instance-groups managed" - basic command

- Create instance groups: create

"gcloud compute instance-groups managed create NAME --zone ZONE --template
TEMPLATE --size 1(no. of instance)"
--health-check=HEALTH_CHECK: How do you decide if instance is
healthy
--initial-delay: How much time should you give to an instance to
start?
Other similar commands: gcloud compute-instance-groups managed
delete/describe/list

- Setup Autoscaling: set-autoscaling/stop-autoscaling

"gcloud compute instance-groups managed set autoscaling NAME --max-num-
replicas=10
--cool-down-period(default - 60s): How much time should auto
scaler wait after initiating an autoscaling action?
--scale-based-on-cpu --target-cpu-utilization --scale-based-on-
load-balancing --target-load-balancing-utilization
--min-num-replicas --mode(off/on(default)/only-scale-out)

"gcloud compute instance-groups managed stop-autoscaling NAME(my-mig for

ex)

- Updating existing MIG policies(ex: auto healing policies):

"gcloud compute instance-groups managed update NAME"
--initial-delay: How much time should you give to the instance
to start before marking it unhealthy?
--health-check: How do you decide if an instance is healthy

--> Playing with Managed Instance Groups - Making Updates

- Resize the group:
- "gcloud compute instance-groups managed resize NAME --size=5

- Recreate one or more instances(delete and recreate instances):

- "gcloud compute instance-groups managed recreate-instances NAME --
instances=my-instance-1, my-instance-2" Replace the instances name with the

existing one

- Update specific instances:

- gcloud compute instance-groups managed update-instances NAME --
instances=INSTANCE_NAME_1, INSTANCE_NAME_2"(Update specific instances from the
group)
--minimal-action=none(DEFAULT)/refresh/replace/restart

--most-disruptive-allowed-action=none(default)/refresh/replace/restart

- Update instance template:

- gcloud compute instance-groups managed set-instances-template NAME --
template=v2-template
After updating instance template, you can trigger roll out of the
new template using "update-instances", "recreate-instances" or "rolling-
action start-update commands"

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-- Playing with Managed Instance Groups - Rolling Actions

- Scenario: You want to manage your new release - v1 to v2 - without downtime

- "gcloud compute instance-groups managed rolling-action"

- Restart(stop and start) - gcloud compute instance-groups managed rolling-action

restart my-mig(NAME)
--max-surge=5 or 10%(Maximum number of instances updated at a time)

- Replace(delete and recreate) - gcloud compute instance-groups managed rolling-

action replace my-mig
--max-surge=5 or 10%(Max no if instances updated at a time)
--max-unavailable=5 or 10%(Max no of instances can be down for the update)
--replacement-method=recreate/substitute (substitute (default) creates
instances with new names, recreate reuses name)

- Update instances to a new template

Basic version (Update all instances slowly step by step) - gcloud compute
instance-groups managed rolling-action start-update my-mig[NAME] --
version=template=v1-template[NAME OF NEW TEMPLATE]
Canary Version (Update a subset of instances to v2) - gcloud compute
instance-groups managed rolling-action start-update my-mig --version=template-v1-
template --canary-version=template=v2-template,target-size=10%

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------
===================================================================================
=========================================================================

4. Load Balancing in GCP

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Cloud Load Balancing

- Distributes user traffic across instances of an application in single or multiple

regions
- Fully distributed, software defined managed service

- Important Features
- Health Check - Route to healthy instances
Recover from failure

- Auto Scaling

- Global load balancing with single anycast IP

- Also supports internal load balancing

- Enables:
High Availability
Auto Scaling
Resiliency

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Creating a Load Balancer

--> Demo

- Search Load Balancing(Network Services) >> Create Load Balancer(HTTP(S), TCP,

UDP) >> Internet Facing/Internal Load Balancer >> Single/Multi Region

NOTE: UDP is only single region

NOTE: TCP provides more resiliency than UDP but UDP provides you more performance
than TCP.

- A Load Balancer in GCP usually consists of three sections:

i. Backend Configuration:
Configure Managed Instance Group

Create a backend service >> Name >> Choose the instance

group(MIG) >> Configure port no. >> Balancing Mode(Utilization/Rate of
Request) >> Health Check >> Choose the backend service

NOTE: Can create multiple backends

 NOTE: Can enable CDN(Content Delivery Network)

ii. Host and Path Rules

Lets you determine how your traffic will be redirected to the
backend

iii. Frontend Configuration:

URL for the load balancer, Where do you want to receive the
request at.

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Cloud Load Balancing - Terminology

- Backend - Group of endpoints that receive traffic from Google cloud load
balancer(example: instance group(usually MIGs))

- Frontend - Specify an IP address and protocol. This IP address is the frontend IP

for your clients requests

- Host and Path Rules(For HTTP(S) Load Balancing) - Define rules redirecting the
traffic to different backends:
Based on path - ABC.com/a vs ABC.com/b
Based on host - a.ABC.com vs b.ABC.com
Based on HTTP headers (Authorization header) and methods(POST, GET, etc)

SSL Termination/Offloading - Layer 7

TLS Termination/Offloading - Layer 4

Client < ------------ > Google Load Balancer < --------------- > VM
Instances

- Client to load balancer: Over internet

- HTTPS recommended

- Load Balancer to VM instances: Through Google internal network

- HTTP is OK. HTTPS is preferred

- SSL/TLS Termination/Offloading
- Client to Load Balancer: HTTP/TLS
- Load Balancer to VM instance: HTTP/TCP

Hierarchy --> Instance Template >> Instance Group >> Load Balancer

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Choosing the Load Balancer

- 1. External Traffic

IPv4/IPv6 clients >> External LB >> i. HTTP/HTTPS Traffic >> Regional? >>
Regional LB(If the traffic is Regional)
ii. HTTP/HTTPS Traffic >> Regional? >>
External/Classic LB(If the traffic is global)
iii. TCP traffic >> SSL Offload(Yes) >>
SSL proxy
iv. TCP traffic >> SSL Offload(No) >>
Need Global LB or IPv6 >> TCP proxy
v. TCP traffic >> SSL offload(No) >>
Preserve client IP(Yes) >> External Network LB
vi. External LB is also recommended for
UDP and ICMP traffic

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Cloud Balancing Feature

Load balancer >> Types of Traffic >> Proxy or Pass-Through >> Destination Ports

i. External HTTP(s) >> Global, External, HTTP or HTTPS >> Proxy >> HTTP on 80/8080,
HTTPS on 443
ii. Internal HTTP(S) >> Regional, Internal, HTTP or HTTPS >> Proxy >> HTTP on
80/8080, HTTPS on 443
iii. SSL Proxy >> Global, External, TCP with SSL Offload >> Proxy >> A big list
iv. TCP Proxy >> Global, External, TCP without SSL Offload >> Proxy >> A big list
v. External Network(TCP/UDP) >> Regional, External, TCP, or UDP >> Pass-Through >>
any
vi. Internal TCP/UDP >> Regional , Internal, TCP, or UDP >> Pass-through >> any

NOTE: Proxy requests are those in which content is hidden whereas Pass-through are
ones in which information is visible

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Load Balancer Scenarios

- 1. You want only health instances to receive traffic

Configure health check

- 2. You want high availability for your VM instances

Create multiple MIGs for your VM instances in multiple regions. Load Balance
using a LB.

- 3. You want to route requests to multiple microservices using the same load
balancer

Create individual MIGs and backends for each microservices. Create host and
path rules to redirect to specific microservice backend based on the
path(/microservice-a, /microservice-b etc). You can route to a backend Cloud
Storage Bucket as well.

- 4. You want to load balance Global external HTTPS traffic across backend
instances, across multiple regions

Choose External HTTP(S) Load Balancer

- 5. You want SSL termination for global non-HTTPS traffic with load balancing

Choose SSL Proxy Load Balancer.

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================

5. Managed Service
in GCP

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Managed Services

- Do you want to continue running applications in the cloud, the same way you run
them in your data center?

- OR are there OTHER approaches?

- You should understand some terminology used with cloud services:

- IaaS (Infrastructure as a Service)

- PaaS (Platform as a Service)
- FaaS (Function as a Service)
- CaaS (Container as a Service)
- Serverless

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> 1. IAAS(Infrastructure as a Service)

- Use only infrastructure from cloud provider

- Example: Using VM to deploy your applications or databases

- You are responsible for:

- Application code and runtime
- Configuring load balancing
- Auto Scaling
 - OS upgrades and patches
- Availability

- The CSP is responsible for:

- Virtualization
- Physical Infrastructure
- Networking

--> 2. PAAS(Platform as a Service)

- Use a platform provided by cloud

- CSP is responsible for

- OS(incl. upgrades and patches)
- Application Runtime
- Auto Scaling, Availability, and Load Balancing

- You are responsible for:

- Configuration(of Application and Services)
- Application code(if needed)

- Varieties:
- CAAS(Container as a Service): Container instead of Apps
- FAAS(Function as a Service): Functions instead of Apps
- Databases - Relational and NoSQL, Queues, AI, ML, Operations, etc.

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Microservices

- Enterprises are heading towards microservices architectures

- Build small focused microservices
- Flexibility to innovate and build applications in different
programming languages(Go, Java, python, or JavaScript..) microservices

- How can we have one way of deploying Go, Java, Python, or JavaScript..
Applications/Microservices.
- Enter Containers

--> Containers - Docker

- Create Docker images for each microservice

- Docker image has all needs of a microservice:

- Application Runtime(JDK or Python or NodeJS)
- Application code and Dependencies

- Runs the same way on any infrastructure

- Your local machine
- Corporate Data Center
- Cloud

- Advantages
- Docker containers are lightweight
Compared to VMs they do not have a guest OS
 - Docker provides isolation for containers
- Docker is cloud neutral

--> Container Orchestration(Ex: Kubernetes)

- Say you have made docker images of your application to use it everywhere but how
do deploy it to a cluster of VMs?

- Here a container orchestrator is used(usually Kubernetes)

- Requirement: I want 10 instances of Microservice A container, 15 instances of

Microservice B container and so on...

- Typical Features of container orchestrator:

- Auto Scaling: Scale containers based on demand
- Service Delivery: Help microservice find each other
- Load Balancer: Distribute load among multiple instances of a
microservice
- zero Downtime Deployments: Release new versions without downtime

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Serverless

- What do we think about when we develop an application?

- Where to deploy? What kind of server? What OS?
- How do we take care of scaling and availability of the application

- What if you don't need to worry about servers and focus on your code?
- Enter Serverless
- Remember: Serverless does NOT mean "No Servers"

- Serverless for me:

- You do not need to worry about infrastructure(ZERO visibility into
infrastructure)
- Flexible scaling and automated high availability

- Most important: Pay for use

- Ideally ZERO REQUESTS => ZERO COST

- You focus on code and the cloud managed service takes care of all that is
needed to scale your code to serve million of requests!
- And you pay for requests and NOT servers!

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Serverless - Perspective?

- Serverless -Important Features:

- 1. Zero worry about infrastructure, scaling and availability

- 2. Zero Invocations => Zero Cost (Can you scale down to Zero
instances?)
 - 3. Pay for invocations and NOT for instances( or nodes or servers)

- Serverless Level 1: Features(1+2)

- Serverless Level 2: Features(1+2+3)

- When I refer to Serverless, I'm referring to Level 2

- HOWEVER cloud providers include managed services at L1 and L2:

- Level 1: Google App Engine (Google calls it "App Engine is a fully
managed, serverless platform"), AWS Fargate(AWS calls it "serverless compute
engine for containers")
- Scale down to ZERO instances when there is no load, BUT you
pay for number(and type) of instances running!
- Level 2: Google Functions, AWS Lambda, Azure Functions etc..

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> GCP Managed Service for Compute

- 1. Compute Engine: High performed and general purpose VMs that scale gradually
-- IaaS

- 2. Google Kubernetes Engine: Orchestrate containerized microservices on

Kubernetes. -- CaaS
Needs advanced cluster configurations and monitoring

- 3. App Engine: Build highly scalable applications on a fully managed platform

using open and familiar languages and tools -- PaaS(CaaS, Serverless)

- 4. Cloud Functions: Build event driven applications using simple, single purpose
functions -- FaaS, Serverless

- 5. Cloud Run: Develop and deploy scalable containerized applications. Does NOT
need a cluster --CaaS(Serverless)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================

6. App Engine

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> App Engine

- Simplest way to deploy and scale your applications in GCP
- provides end-to-end application environment

- Supports:
- Go, Java, Node.js, PHP, Python, Ruby, using pre-configured runtimes
- Use custom run-time and write code in any language
- Connect to variety of Google Cloud storage products(Cloud SQL etc)

- No Usage charges: Pay for resources provisioned

- Features:
- Automatic load balancing and Auto scaling
- Managed platform updates and Application health monitoring
- Application versioning
- Traffic Splitting

--> Compute Engine vs App Engine

- Compute Engine
- IAAS
- More Flexibility
- MORE Responsibility
- Choosing Image
- Installing Software
- Choosing Hardware
- Fine grained Access/Permissions(Certificates/Firewalls)
- Availability

- App Engine
- PaaS
- Serverless
- LESSER Responsibility
- LOWER Flexibility

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> App Engine Environments

- Standard: Applications run in language specific sandboxes

- Complete isolation from OS/Disk/Other Apps

- V1: Java, Python, PHP, Go (OLD Versions)

- Only for python and PHP runtime:
Restricted Network Access
Only white-listed extensions and libraries are allowed
- No Restrictions for Java and Go runtimes

- V2: Java, Python, PHP, Node.js, Ruby, Go (NEWER Environments)

- Full network access and no restrictions on language extensions

- Flexible: Application instances run within docker containers

- Makes use of Compute Engine virtual machines
- Support ANY runtime(with built-in support for python, java, Node.js,
Go, Ruby, PHP, or .NET)
- Provides access to background processes and local disk's
-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> App Engine- Application Component Hierarchy

Application
|

---------------------------------------------
|
|
Service
Service
|
|
-------------------
-------------------------
| | |
|
Version Version
|
--------------
| |
Instance Instance

- Application: One App per Project

- Service(s): Multiple Microservices or App Components

- You can have multiple services in a single application
- Each service can have different settings
- Earlier called as "modules"

- Version(s): Each version associated with code and configuration

- Each Version can run in one or more instances
- Multiple versions can co-exist
- Options to rollback and split traffic

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

App Engine - Comparison

FEATURE STANDARD
FLEXIBLE

1. Pricing Factors Instance Hours

vCPU, Memory, and Persistent Disks

2. Scaling Manual, Basic, Automatic

Manual, Automatic

3. Scaling to Zero Yes

No

4. Instance Startup Time Seconds

Minutes
5. Rapid Scaling Yes
No

6. Max Request Timeout 1 to 10 minutes

60 minutes

7. Local Disk Mostly(Except for python, PHP).

Yes. Ephemeral. New Disk on Startup
Can write to /tmp

8. SSH for debugging No

Yes

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> App Engine - Scaling Instances

- 1. Automatic: Automatically scale instances based on the load:

- Recommended for Continuously Running Workload
- Auto Scale based on:
- Target CPU Utilization: Configure a CPU usage
threshold
- Target Throughput Utilization: Configure a
throughput threshold
- Max Concurrent Requests: Configure maximum
concurrent requests an instance can receive
- Configure Max Instances and Min Instances

- 2. Basic: Instances are created as and when requests are received:

- Recommended for Ad-hoc workloads
- Instances are shutdown if ZERO requests
- Tries to keep costs low
- High latency is possible
- NOT supported by App Engine "Flexible"
- Configure Max Instances and Idle Timeout

- 3. Manual: Configure specific number of instances to run

- Adjust number of instances manually over time

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> App Engine - Demo

For this lab, download the file provided in the course

>> Project >> New Project >> Name the Project

>> App Engine >> Enable API(Search App Engine Admin API) >> Choose Region >>
Language >> Environment

>> Cloud Shell >> Open Editor >> Open in New Window >> Open Folder >> Choose the
home Folder >> Select the files from the downloaded file >> Drag and Drop
on the explorer part of the console
>> "cd default-services" >> "gcloud config list" >> "gcloud config set project
PROJECT_ID" >> "gcloud app deploy" >> press Y >> Error(permission denied) >>
IAM >> Edit member >> edit role >> select a role >> storage object viewer
permission >> save >> deploy again >> use the URL generated to access

>> Services(default service) >> Versions >> Instances

>> "gcloud app services list" >> "gcloud app versions list" >> "gcloud app
instances list"

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> To deploy another version of the new service

>> "gcloud app deploy --version=v2" >> Yes >> "gcloud app browse" >> "gcloud app
browse --version=VERSION_ID"(to list the URL of previous versions)

NOTE: app.yaml: Configuration for app engine for specific file

main.py: Main python code
Requirements.txt: Dependencies of specific application

NOTE: In one project only one App Engine can run

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Splitting Traffic between two versions

>> create a new version of the application >> Now you do not want to switch traffic
immediately and want the current version to be live but slowly switch the traffic
>> "gcloud app deploy --version-v3 --no-promote >> Yes >> Use the URL generated to
test it.

>> "gcloud app services set-traffic --splits=v3=.5, v2=0.5" >> "watch curl URL"(to
check the requests)

>>"gcloud app services set-traffic --splits=v3=.5, v2=.5 --split-by=random" --->

Splitting traffic randomly

>> "gcloud app services set-traffic --splits=v3=1" --> Set traffic to v3

NOTE: 1 means full traffic, .5 is half

NOTE: You can also split traffic by cookie

NOTE: Splitting traffic by IP is the default option but not a good idea as it may
cause confusion

NOTE: --promote is used to make a service available

NOTE: You can also perform the above steps in the UI

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------
--> Creating New Service and Playing with App Engine

- Apart from the default service you can perform number of other additional
services

>> "cd ../my-first-service/" >> "gcloud app deploy" >> Yes >> "gcloud app services
list"

>> "gcloud app browse"(active version of default service) >> "gcloud app browse --
service=SERVICE_NAME"(activate your required service)

>> "gcloud app browse --service=SERVICE_NAME --version=VERSION" (URL to specific

version)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Understanding App Engine app.yaml

- Go through the video again to know how to configure services in app.yaml file

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> App Engine - Request Routing

- You can use a combination of three approaches:

- Routing with URLs:

- "https://PROJECT_ID.REGION_ID.r.appspot.com" (default service
called)
- "https://SERVICE-dot-PROJECT_ID_REGION_ID.r.appspot.com" (specific
service)
- "https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.appspot.com"
(specific version of service)
- Replace -dot with . if using a custom domain

NOTE: App Engine >> App Engine Setting >> Custom Domain

- Routing with a dispatch file:

- Configure dispatch.yaml with routes
- gcloud app deploy dispatch.yaml

- Routing with Cloud Balancer

- Configure routes on Load Balancing instances

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> App Engine - Deploying new versions without downtime

- How do I go from V1 to V2 without downtime

- OPTION 1: I am very confident - Deploy and Shift all traffic at once:

- Deploy and shift all traffic at once from v1 to v2: "gcloud app
deploy"

- OPTION 2: I want to manage the migration from v1 to v2

- STEP 1: Deploy v2 without shifting traffic(--no-promote)
- "gcloud app deploy --no-promote"

- STEP 2: Shift traffic to v2:

- OPTION 1: (All at once Migration): Migrate at once to v2
- "gcloud app service set-traffic s1 --splits
v2=1

- OPTION 2: (Gradual Migration): Gradually shift traffic to

v2. Add --migrate option.
- Gradual migration is not supported* by App
Engine Flexible Environment

- OPTION 3: (Splitting): Control the pace of migration

- gcloud app services set-traffic s1 --
splits=v2=.5, v1=.5
- Useful to perform A/B testing

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Splitting Traffic Between Multiple Version

- How do you decide which version receives which traffic ?

- IP Splitting - Based on request IP address

- IP Addresses can change causing accuracy issues!( I go from my house
to a coffee shop)
- If all requests originate from a corporate VPN with single IP, this
can cause all requests to go to the same version

- Cookie Splitting - Based on cookie (GOOGAPPUID)

- Cookies can be controlled from your application
- Cookie splitting accurately assign users to version

- Random: Do it Randomly

- How do I do it?

- Include --split-by option in gcloud app service set-traffic command

- Value must be one of: cookie, IP, random

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Playing with APP Engine - Commands to remember

- gcloud app browse/create/deploy/describe/open-console

- "gcloud app create --region=us-central"

- "gcloud app deploy app.yaml"

- "--image-url": Only for Flexible environments. Deploy docker image
 - "gcloud app deploy --image-url gcr.io/PROJECT-ID/hello-
world-rest-api:0.0.1.RELEASE
- "--promote --no-promote (Should version receive traffic?)
- "--stop-previous-version --no-stop-previous-version (Should old
version be stopped after new version receives all traffic?)
- "--version (Assign a version. Otherwise, a version number is
generated)

- gcloud app browse --service="myService" --version="v1" (open in a web

browser)

- gcloud app open-console --service="myService" --version="v1"

- gcloud app open-console --logs

- Other Commands

- gcloud app logs trail

- gcloud app regions list

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Playing with App Engine Instances

- gcloud app instances delete/describe/list/scp/ssh

- gcloud app instances delete i1 --service=s1 --version=v1
- gcloud app instances describe --service=s1 --version=v1 i1
- gcloud app instances list (If using standard app engine, initially the
instances are scale to zero, but if you fire up a request ypu will find
the instance. )
- gcloud app instances scp --services=s1 --version=v1 --recurse local-dir
i1:remote_dir
(Copy files to/from App Engine Flexible Instances)
- gcloud app instances ssh --services=s1 --version=v1 i1 (SSH into the VM
of an APP Engine Flexible instance)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> playing with App Engine Services and Versions

- gcloud app services browse/delete/describe/list/set-traffic

- gcloud app services list
- gcloud app services browse myService --version="v1"
- gcloud app services delete service1 service2
- gcloud app service describe service1
- gcloud app service set-traffic APP1 --splits v1=0.9,v2=0.1
--split_by (IP, cookie, random)

- gcloud app version browse/delete/describe/list/migrate/start/stop

- gcloud app versions list
--hide-no-traffic (Only show versions that are receiving traffic)
- gcloud app versions browse/delete/describe v1 --service="myService"
- gcloud app versions migrate v2 --service="myService" (migrate all traffic to
new version)
- gcloud app versions start/stop v1
--service=my-service Only start v1 of service my-service

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> App Engine - Cron Job

- Allows to run "scheduled jobs" at pre-defined intervals

- Use Cases:
- Send a report by email every day
- Refresh cache data every 30minutes

- Configured using cron.yaml

- Run this command - "gcloud app deploy cron.yaml"

- Perform a HTTP GET request to the configured URL on schedule

- Example Cron Script:

Cron:
- description: "daily summary job"
url1: /tasks/summary
schedule: every 24 hours

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Other Important App Engine yaml files

- dispatch.yaml - Override routing rule

dispatch:
- url: "*/mobile/*" (specify the url)
service: mobile-frontend (specify the service for the
traffic)
- url: "*/work/*"
service: static-backend

- queue.yaml - manage task queues

queue:
- name: fooqueue
rate: 1/s
retry_parameters:
task_retry_limit: 7
task_age_limit:2d

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> App Engine - Remember

- App Engine is Regional(services deployed across zone)
- You CANNOT change an Application's region

- Good option for simple microservices(multiple services)

- Use Standard v2 when you are using supported languages
- Use Flexible if you are building containerized apps

- Be aware: ATLEAST one container is always running when using Flexible:

- Go for standard if you want to be able to scale down the number of
instances to zero when there is NO load

- Use a combination of resident and dynamic instances

- Resident Instances: Run Continuously
- Dynamic Instances: Added based on load
- If you are not cost sensitive, keep a set of resident instances running

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> App Engine - Scenarios

- Scenario 1: I want to create two Google App Engine Apps in the same project
- Not possible. You can only have one App Engine App per project.
However you can have multiple service and multiple versions for each service

- Scenario 2: I want to create two google app engine services inside the same app
- Yes. You can create a multiple services under the same app. Each
service can have multiple versions as well

- Scenario 3: I want to move my Google app engine app to a different region

- App Engine App is region specific. You CANNOT move it to different
region. Create a new project and create new app engine app in the new
region

- Scenario 4: Can you perform canary deployments

- Deploy v2 without shifting traffic(gcloud app deploy --no-promote)
- Shift some traffic to V2(gcloud app services set-traffic s1 --
splits v1=0.9, v2=0.1)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================

7. GKE: Google
Kubernetes Engine

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Kubernetes

Container Image
Configuration
|
|
|
|
|
|
|
______________________________________________________________|
|
|
|
|
Container
Orchestrator(Kubernetes)
|
|
|
|
Cluster
|
|
_______________________________|
__________________________________
| |
|
Virtual Server 1 Virtual
Server 2 Virtual Server 3

- Most popular open source container orchestration solution

- Provides cluster management(including upgrades)

- Each cluster can have different types of virtual machine

- Provides all important container orchestration features:

- Auto Scaling
- Service Discovery
- Load Balancer
- Self Healing
- Zero downtime deployments

--> Google Kubernetes Engine(GKE)

- Managed Kubernetes Service

- Minimize operations with auto-repair (repair failed nodes) and auto-upgrade (use
latest version of k8 always) features

- Provides Pod and Cluster Autoscaling

- Enable Cloud Logging and Cloud Monitoring with simple configuration

- Uses Container-Optimized OS, a hardened OS built by Google

- Provides support for Persistent disks and Local SSD

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Kubernetes - A Microservice Journey - Getting Started

- Let us create a cluster, deploy a microservice and play with it

- 1. Create a Kubernetes cluster with the default node pool

- "gcloud container clusters create" or use cloud console
- “gcloud container clusters create my-cluster --zone us-central1-a”

NOTE: For Kubernetes the command usually starts with "gcloud container"

NOTE: Always remember to enable APIs of particular service

>> Kubernetes Engine >> Create Cluster >> Standard(Complete

Ownership)/Autopilot(GKE) >> Standard >> Configure >> Name >> Zonal/Regional >>
Create

--> Autopilot Mode - GKE

- New mode of operation for GKE

- Reduce your operational costs in running Kubernetes clusters

- Provides an hands-off experience

- Do not worry managing the cluster infrastructure(nodes, node pools...)
- GKE would completely manage the clusters

- 2: Login to Cloud Shell

- 3: Connect to the Kubernetes Cluster

- A cluster by default is of 3 nodes

>> "gcloud config set project PROJECT_ID" >> "gcloud container clusters get-
credentials NAME --zone-us-central1-c --project PROJECT_NAME"

NOTE: You need to connect to the clusters using either the console or command line

NOTE: Remember the command for connecting to the clusters as it is important

"gcloud container clusters get-credentials NAME ZONE --project
PROJECT_ID"
NOTE: If you want to access the contents of a cluster you need to
expose it
 "kubectl expose deployment hello-world-rest-api --type=LoadBalancer
--port=8080"

--> A Microservice Journey - Deploy Microservice

- 4: Deploy Microservice to Kubernetes:

- Create deployment and service using "kubectl" commands
- "kubectl create deployment NAME_OF_DEPLOYMENT --image=IMAGE"
kubectl create deployment hello-world-rest-api --
image=in28min/hello-world-rest-api:0.0.1.RELEASE

>>kubectl create deployment hello-world-rest-api --image=in28min(DOCKER_ID)/hello-

world-rest-api:0.0.1.RELEASE >> kubectl get deployment(CHECK_STATUS) >>
kubectl expose deployment hello-world-rest-api --type=LoadBalancer --
port=8080(CREATE_SERVICE) >> kubectl get services >> kubectl get services --watch
>> Take a note on the EXTERNAL_IP of LB >> curl EXTERNAL-IP:PORT(should return
healthy:true) >> curl EXTERNAL-IP:PORT/hello-world

NOTE: If you want to deploy/expose a microservice use "kubectl"

Cluster
|
|
|

-----------------------------------------------------------------------------------
--------------------
| |
|
| |
|
| |
|
Node Pool 1 Node Pool 2
Node Pool 3......
|
|
|
-----------------------
| |
Node 1 Node 2

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Exploring GKE

- In default, one node pool with three nodes are created

- You can add node pool according to your specification

>> do a walkthrough >> Workloads >> Services and Ingress(Rules for Routing External
HTTP Traffic)

--> Kubernetes: A Microservice Journey - Deploy Microservice:

- 5: Increase number of instances of your microservice:(POD scaling)

>> "kubectl scale deployment NAME_OF_DEPLOYMENT --replicas=3" >> kubectl get

deployment >> watch curl URL
NOTE: Each instance here is called pod

>> kubectl get pods (Info of running pods)

- 6: Increase number of nodes in your Kubernetes cluster: (Cluster Scaling)

gcloud container clusters resize CLUSTER_NAME --node-pool POOL_NAME --
num-nodes=2 --zone=us-central1-c

--> Auto-Scaling

- 7: Setup auto scaling for your microservice:

- kubectl autoscale deployment DEPLOYMENT_NAME --max=10(MAX Instance)
--cpu-percent=70(VECTOR) --> Auto-scale the number of pods
- Also called horizontal pod autoscaling - HPA - "kubectl
get hpa"

- 8: Setup auto scaling for your Kubernetes Cluster

- gcloud container clusters update CLUSTER_NAME --enable-autoscaling --
min-nodes=1 --max-nodes=10 --> Auto-scale the number of nodes

- 9: Add some application configuration for your microservice

- Config Map: "kubectl create configmap todo-web-application-

config(NAME) --from-literal=RDS_DB_NAME=todos"
- kubectl get configmap
- kubectl describe configmap NAME
- kubectl edit configmap todo-web-application-config (to edit the
config-map)

NOTE: configmap in simple words: Say you need to make some changes in the
configuration of an application, after sometime, at some part. Instead of
rewriting it as a whole you can create a configmap where you can make the
changes there. Say URL, Tokens, SSL.

-10. Add password configuration for your microservice(Storing passwords a secret)

- Kubernetes Secrets: "kubectl create secret generic todo-web-

application-secrets-1(NAME) --from-literal=RDS_PASSWORD=dummytodos
- kubectl get secret
- kubectl describe secret SECRET_NAME

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Exploring GKE - Using YAML

>> Click on the cluster >> Instead of entering commands in command line, you can
edit the yaml file >> overview, details, events, logs, YAML

NOTE: You can deploy Kubernetes using two methods:

 1. Using command line: also called imperative
2. Using YAML: also called declarative

>> "kubectl apply -f deployment.yaml(NAME_OF_FILE)"

NOTE: Look at the deployment and Service file provided in the course

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Kubernetes - A Microservice Journey

- 11. Deploy a new microservice which needs nodes with a GPU attached
- Attach a new node pool with GPU instances to your cluster
- "gcloud container node-pools create POOL_NAME --cluster
CLUSTER_NAME"
- "gcloud container node-pools list --cluster CLUSTER_NAME"

- Deploy the new microservice to the pool by setting up nodeSelector

in the deployment.yaml
- nodeSelector: cloud.google.com/gke-nodepool: POOL_NAME

- 12: Delete the Microservice

- Delete service -kubectl delete service
- Delete Deployment - kubectl delete deployment

- 13. Delete the cluster

- gcloud container cluster delete

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Google Kubernetes Engine(GKE) Cluster

- Cluster: Group of Compute Engine Instances:

- Master Node(s): Manages the cluster

- Worker Node(s): Run your workloads (pods)

- Master Node (Control Plane) components:

- API Server: Handles all communication for a K8S cluster(from nodes

and outside)
- Scheduler - Decides placement of pods
- Control Manager - Manages deployments and replica sets
- etcd - Distributed database storing the cluster state

- Worker Node components:

- Runs your pods

- Kubelet: Manages communication with master Node(s)

--> GKE Cluster Types

- 1. Zonal Cluster: Single Zone - Single Control planes. Nodes running in the same
zone
 Multi-zonal - Single Control plane, but nodes running in
multiple zones

- 2. Regional Cluster: Replicas of the control plane runs in multiple zones of a

given region. Nodes also run in the same zones where control plane runs.

- 3. Private Cluster: VPC-native cluster. Nodes only have internal IP addresses

- 4. Alpha Cluster: Clusters with alpha APIs - early feature API's. Used to test
new K8S features.

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Kubernetes - Pods

- Smallest deployable unit in Kubernetes

- A pod contains one or more container(usually one pod contains one container)

- Each pod is assigned an ephemeral IP address(once a pod is killed a new IP is

generated)

>> kubectl get pods(Info on pods) >> kubectl get deployment(No. of nodes) >>
kubectl get deployment -o wide >> kubectl get pods -o wide

- All containers in a pod share:

- Network
- Storage
- IP Address
- Pods
- Volumes(Shared persistent disks)

- POD Statuses: Running/ Pending/ Succeeded/ Failed/ Unknown

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

Kubernetes - Deployment vs Replica Set

- A deployment is created for each microservice:

- kubectl create deployment m1 --image=m1 :v1

- Deployment represents a microservice (with all its releases)
- Deployment manages new releases ensuring zero downtime

Cluster
|
|_ _ _Node 1(use resize to scale up/down)
| |
| |_ _ _ Pod 1 (use replica to scale up/down) - Deployment (Microservice)
| | |
| | |_ _ _ Container 1 (Running micro-service-1)
| | |
| | |_ _ _ Container 2 (Running micro-service-2)
| |
| |_ _ _ Pod 2
| |
| |_ _ _ Container 1
|
|
|_ _ _Node 2

**- Update the deployment(Micro-Service)

- kubectl set image deployment DEPLOY_NAME DEPLOY_CONT=IMG
"kubectl set image deployment hello-world-rest-api hello-world-
rest-api=in28min/hello-world-rest-api:0.0.2.RELEASE
- kubectl get services(To get URL)

- Replica set ensures that a specific number of pods are running for a specific
microservice version.
**NOTE: Say you have replica set for v1 and updated the deployment to v2, still
the replica sets are of v1

- kubectl get replicasets (Prints number of pods)

>> “kubectl logs POD_NAME” >> logs of the pod

>> “kubectl exec -it POD_NAME --bin/bash” >> Enter the container bash

>> kubectl delete pod >> kubectl delete pod POD_NAME >>

NOTE: As soon as a pod is deleted, a new pod is initiated

- kubectl scale deployment m2 --replica=2

- Even if one of the pods is killed, replica set will launch a new one

NOTE: If you update a deployment, the old deployment still exists with replica
sets(pods), if you want new replica sets pods for the updated version, you
need to scale it up again

- Deploy v2 of microservice - Create a new replica set

- kubectl set image deployment m1 m1=m1:v2
- v2 replica set is created
- Deployment updates v1 replica set and v2 replica set based on the release
strategies

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Kubernetes - Service

- Each pod has its own IP address:

- How do you ensure that external users are not impacted when:
- A pod fails and is replaced by replica set
- A new release happens and all existing pods of old release are
replaced by ones of new release

- Create Service
- kubectl expose deployment name --type=LoadBalancer --port=80
- Expose PODs to outside world using a stable IP address
 - Ensures that the external world does not get impacted as pods
go down and come up

- Three Types:

- ClusterIP: Exposes Service on a cluster-internal IP

- Use case: You want your micro-service only to be available
inside the cluster (intra cluster communication)

- LoadBalancer: Exposes Service externally using a cloud provider's load

balancer
- Use case: You want to create individual Load Balancer's for each
microservice

- NodePort: Exposes Service on each Node's IP at a static port (the

NodePort)
- Use case: You DO NOT want to create an external load balancer
for each microservice (You can create one Ingress component to load balance
multiple microservice)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Container Registry - Image Repository(Artifacts and Registry)

- You have created docker images for your microservice

- Where do you store them

- Container Registry - fully-managed container registry provided by GCP

- (Alternative) Docker Hub

- Can be integrated to CI/CD tools to publish images to registry

- You can secure your container images. Analyze for vulnerabilities and enforce
deployment policies

- Naming: HostName/ProjectID/Image:Tag - gcr.io/projectname/helloworld:

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

GKE Remember:

- Replicate master nodes across multiple zones for high availability

- (REMEMBER) Some CPU on the nodes is reserved by Control Plane:

1st core - 6%, 2nd Core - 1%, 3rd/4th - 0.5%, Rest - 0.25

- Creating Docker Image for your microservice(Dockerfile):

- Build Image: docker build -t TAG
“docker build -t in28min/hello-world-rest-
api:0.0.1.RELEASE”
- Test it Locally: docker run -d 8080:8080 in28min/hello-world-rest-
api:0.0.1.RELEASE”
- Push it to Container Repository: docker push in28min/hello-world-rest-
api:0.0.1.RELEASE

- Kubernetes supports Stateful deployments like Kafka, Redis, ZooKeeper:

- Stateful: Set of pods with unique, persistent identities and stable
hostnames

- How do we run services on nodes for log collection or monitoring ?

- DaemonSet - One pod on every node! (for background services)

- (Enabled by default) integrates with Cloud Monitoring and Cloud Logging

- Cloud Logging Systems and Application Logs can be exported to BigQuery or
Pub/Sub

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

Google Kubernetes Engine - Scenarios - 1

- 1. You want to keep your costs low and optimize your GKE implementation

- Consider PVMs, Appropriate region, Committed-use discounts

- E2 machine types are cheaper than N1
- Choose right environment to fit your workload type (Use multiple node pools
if needed).

- 2. You want an efficient, completely auto scaling GKE solution

- Configure Horizontal Pod Autoscaler for deployments and Cluster Autoscaler

for node pools

- 3. You want to execute untrusted third-party code in Kubernetes cluster

- Create a new node pool with GKE sandbox. Deploy untrusted code to sandbox
node pool

- 4. You want to enable ONLY internal communication between your microservice

deployments in a Kubernetes cluster

- Create Service of type: ClusterIP

- 5. My pod stays pending

- Most probably Pod cannot be scheduled onto a node (insufficient resources,

i.e., your node may not have enough resource say memory or cpu to schedule/
wrong path of the image)

- 6. My pod stays waiting

- Most probably failure to pull the image

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------
GKE - Cluster Management - Command Line

- 1. Create Cluster

- gcloud container clusters create CLUSTER_NAME --zone=ZONE

- 2. Resize Cluster

- gcloud container clusters resize CLUSTER_NAME --node-pool POOL_NAME node

10

- 3. Autoscale Cluster

- gcloud container clusters update CLUSTER_NAME --enable-autoscaling -min-

nodes=1 --max-nodes=10

- 4. Delete cluster

- gcloud container clusters delete CLUSTER_NAME

- 5. Adding Node Pool

- gcloud container node-pools create new POOL_NAME --cluster CLUSTER_NAME

-6. List Images

- gcloud container images list

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

GKE - Workload Management -Command Line

- 1. List Pods/Service/Replica Sets

- kubectl get pods/services/replicasets

- 2. Create a Deployment

- kubectl apply -f deployment.yaml or kubectl create deployment

- 3. Create Service

- kubectl expose deployment hello-world-rest-api --type=LoadBalancer --

port=8080

- 4. Scale Deployment

- kubectl scale deployment hello-world --replica=5

- 5. Autoscale Deployment

- kubectl autoscale deployment --max/min --cpu-percent

- 6. Delete Deployment

- kubectl delete deployment DEPLOYMENT_NAME

- 7. Update Deployment

- kubectl apply -f deployment.yaml

- 8. Rollback Deployment

- kubectl rollout undo deployment hello-world --to-revision=1

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> GKE - Deletion of cluster

- kubectl delete service SERVICE_NAME - Delete the service

- kubectl delete deployment DEPLOYMENT_NAME - Delete the deployment

- gcloud container clusters delete CLUSTER_NAME --zone=ZONE - Delete the cluster

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================

8. Google Cloud
Functions

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Cloud Functions

- Imagine you want to execute some code when an event happens?

- A file is uploaded in cloud storage (OR) An error log is written to

Cloud Logging (OR) A message arrives to Cloud Pub/Sub (OR) http/https
invocation is received

- Enter Cloud Functions

- Run code in response to events

- write your business logic in Node.js, Python, Go, Java, .NET, and
Ruby
- Do not worry about servers or scaling or a scalability (only
worry about your code)
 - Pay only for what you use
- Number of invocations
- compute time of the invocations
- memory and CPU provisioned

- Time Bound - default 1 min and MAX 60 minutes(3600 seconds)

- 2 product versions
- Cloud Functions (1st gen): First version
- Cloud Functions (2nd gen): New Function built on top of cloud run
and eventarc

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Cloud Functions - Concept

- Event: Something that has happened. Uploading to a cloud storage

- Trigger: Respond to event with a function call

- Trigger: Which function to trigger when an event happens?

- Functions: Take event data and perform

- Events are triggered from:

- Cloud Storage
- Cloud Pub/Sub
- HTTP POST/GET/DELETE/PUT/OPTIONS
- Firebase
- Cloud Firestone
- Stack driver logging

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Creating a Cloud Functions

>> Cloud Functions >> Enable API >> Create Functions >> 1st/2nd Gen(advanced
features) >> 1st Gen >> Name >> Region >> copy the URL >> Select Trigger Type >>
Allow unauthenticated invocations >> uncheck the http requests >> save >> set
runtime build connections to minimum >> next

>> Configure specific code >> Deploy

>> Select the function >> Testing >> Test the function

NOTE: You can edit the function code whenever you want and you can look at the logs
in the logs section

NOTE: The difference between the 1st and 2nd Gen is the memory and timeout duration
-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Cloud Functions - Remember

- No Server Management: You do not need to worry about scaling or availability of

your function

- Cloud Functions automatically spin up and back down in response to events

- They scale horizontally!

- Cloud Functions are recommended for responding to events

- Cloud Functions are NOT ideal for long running processes

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================

8. Google Cloud Run

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Cloud Run and Cloud Run for Anthos

- Cloud Run: Container to production in Seconds

- Built on top of an open standard - knative
- Fully managed serverless platform for containerized applications
- ZERO infrastructure management
- pay-per-use(For used CPU, Memory, Request and Networking)

- Full integrated end-to-end developer experience:

- No limitations in languages, binaries and dependencies
- Easily portable because of container based architecture
- Cloud Code, Cloud Build, Cloud Monitoring, and Logging Integrations

>> Cloud Run >> Create Service >> Choose the service(image) you want to deploy from
the artifacts and registry section you can also create an image from a source
repository and use the image for deploying >> Name >> Zone >> CPU Allocation(i.
Only allocate when request is raised(charged per invocation), ii. CPU is always
allocated), choose i >> Auto-scaling(can be scaled down to zero but recommended to
1) >> Allow all traffic >> Authentication(Allow unauthenticated request) >> create

>> Inside a service, you can have multiple revisions >> Edit and Deploy a new
revision >> Configure new image, cpu, timeout, max request, autoscaling >> create
Note: Cold Start: If a request is sent to a service and there is no instance, cloud
run will take some time to initiate a new instance

- Anthos: Run Kubernetes clusters anywhere

- Cloud, Multi Cloud and On-premise

- Cloud Run for Anthos: Deploy your workloads to Anthos clusters running on-premise
or on Google Cloud

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Cloud Run - From the Command Line

- 1. Deploy a new container

>> gcloud run deploy SERVICE_NAME --image IMAGE_URL --revision-suffix v1

- First deployment creates a service and first revision
- Next deployment for the same service creates new revisions

- 2. List available revisions

>> gcloud run revisions list

- 3. Adjust traffic assignments

>> gcloud run services update-traffic SERVICE_NAME --to-revisions=v2=10, v1=90

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================

Cloud Functions -
Second Generation

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Cloud Functions - Second Generation - What’s New

- 2 Product Version of Google Cloud Functions

- Cloud Functions (1st gen): First Version
- Cloud Functions (2nd gen): New version built on top of Cloud Run and
Eventarc

- Recommended: Use Cloud Functions (2nd gen)

- Key Enhancement in 2nd gen:

 - Longer Request timeout: Up to 60 minutes for HTTP triggered functions
- Larger instance sizes: Up to 16GB RAM with 4 vCPU (v1: Up to 8GB RAM
with 2 vCPU)
- Concurrency: Up-to 1000 concurrent requests per function instance (v1:
1 concurrent request per function instance)
- Multiple Function Revisions and Traffic Splitting supported (v1: NOT
SUPPORTED)
- Support for 90+ event types - enabled by Eventarc (v1: Only 7)

>> Cloud Function >> Create >> 2nd Gen >> Name >> Region >> Next >> Runtime >>
Deploy >> URL

>> Edit >> Make changes >> Deploy

NOTE: A container image will be built and a service will be created

>> Cloud Run >> you can see a cloud run service created for cloud function >> You
can also see the revisions >> Click on three dots next to the version to “Manage
Traffic”

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Cloud Functions - Scaling and Concurrency

- Typical serverless functions architecture:

- Autoscaling: As new invocations come in, new functions instances are

created

- One function instance handles ONLY ONE request AT A TIME

- 3 concurrent function invocations => 3 function instances

- If a 4th function invocation occurs while existing invocations
are in progress, a new function instance will be created
- HOWEVER, a function instance that completed execution may be
reused for future requests

- (Typical Problem) Cold Start:

- New Function instance initialization from scratch may be used for
future requests
- (SOLUTION) Configure Min number of instances (disadvantage may be
increase in cost)

- 1st Gen uses the typical serverless functions architecture ( The above
architecture)

- 2nd Gen adds a very important new feature:

- One function instance can handle multiple requests AT THE SAME TIME
- Concurrency: How many concurrent invocations can one function
instance handle (MAX 1000)
- (IMPORTANT) Your function code should be safe to execute
concurrently

>> Cloud Functions >> Select a function >> Edit and Deploy new revision >> Scroll
Down >> Maximum requests per container(Set Concurrency for Cloud Function)
-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Cloud Functions - Deployment using gcloud

- gcloud functions deploy NAME

- “--docker-registry” (registry to store the function’s Docker Images)

- Default -container-registry
- Alternative artifact-registry

- “--docker-repository” (repository to store the function’s Docker Images)

- Example:
(projects/${PROJECT}/locations/${LOCATION}/repositories/${REPOSITORY})

- “--gen2 (Use 2nd gen. If this option is not present, 1st gen will be used)

- “--runtime” (nodejs, python, java,...)

- Reference: https://cloud.google.com/functions/docs/runtime-
support

- “--service-account”(Service account to use)

- 1 GEN - default - App Engine default service account -
PROJECT_ID@appspot.gserviceaccount.com
- 2 GEN - Default compute service account - PROJECT_NO-
Compute@developer.gserviceaccount.com

- “--timeout” (function execution timeout)

- “--max-instances” (function execution exceeding max instances time out)

- “--min-instances” (avoid cold start with higher cost)

- “--source”
- zip file from Google Storage
(gs://my-source-bucket/my_function_source.zip) (OR)
- Source Repo (https://URL/project/${PROJECT}/repos/${REPO}) (OR)
- Local file system

- “--trigger-bucket (OR) --trigger-http (OR) --trigger-topic (OR) --trigger-

event-filters (ONLY in gen2 - Eventarc matching criteria for the
trigger)”

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================

Encryption
-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Data States

- 1. Data at Rest: Stored on a device or a backup

- Examples: data on a hard disk, in a database, backups and archive

- 2. Data in motion: Being transferred across a network

- Also called “data in transit”

- Examples:
- Data copied from on-premise to cloud storage
- An application talking to a database

- Two Types:
- In and out of the cloud (The internet)
- Within cloud

- Data in use: Active data processed in a non-persistent state

- Example: Data in your RAM

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Encryption

- If you store data as it is, what would happen if an unauthorized entity gets
access to it?
- Imagine losing an unencrypted hard disk

- First law of security: Defense in Depth

- Typically, enterprise encrypts all data

- Data on your hard disks
- Data in your databases
- Data on your file servers

- Is it sufficient if you encrypt data at rest?

- No, Encrypt data in transit - between application to database as well

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Cloud Key Management Service(KMS)

- Create and manage cryptographic keys (symmetric and asymmetric)

- Control their use in your applications and GCP services (Customer-Managed Key)

- Provides an API to encrypt, decrypt, or sign data

- Use existing cryptographic keys created on premise (Customer-supplied key)

- Integrates with almost all GCP services that need encryption:

- Google-managed keys: No configuration required
- Customer-managed key: Use from the KMS
- Customer-supplied key: Provide your own key

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> KMS DEMO

>> Security >> Cryptographic Keys >> Enable API >> Create a key ring(a key holder)
>> KEY_RING_NAME >> REGIONAL/GLOBAL, GLOBAL >> i. Generate key, ii. Import key,
iii. External key manager(not for global keys) >> KEY_NAME >> Protection
Level(Software/HSM) >> Software >> Purpose >> Symmetric encrypt/decrypt >> Create

- Where and How to use

>> VM Instance >> Management, Security, Disks, Networking, Sole Tenancy >> Disk >>
Customer-managed key >> Grant permission

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================

Block and File Storage in

Google Cloud

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Storage Types - Block Storage and File Storage

- What is the type of storage of your hard disk

- Block Storage

- You have created a file share to share a set of files with your colleagues in a
enterprise. What type of storage are you using?
- File Storage

_____________________ Virtual Server

A _________________________ Storage
|

|
 File Storage ------------------
|
_______ Storage
|
|
|______________________ Virtual Server
B ________________|

|________ Storage

**File Storage
**Block Storage

-->> Block Storage

- Use Cases: Hard disks attached to your computers

- Typically, one block storage device can be connected to ONE virtual server
- (EXCEPTIONS) You can attach read only block devices with multiple
virtual servers and certain cloud providers are exploring multi-writer disks
as well

- HOWEVER, you can connect multiple different block storage devices to one virtual
server

- Used as,
- Direct Attached Storage(DAS): Similar to a hard disk
- Storage Area Network(SAN): High speed network connecting a pool of
storage devices
Used by databases - Oracle and Microsoft SQL
Server

-->> File Storage

- Media workflows need huge shared storage for supporting processes like video
editing

- Enterprise users need a quick way to share files in a secure and organized way

- These file shares are shared by several virtual servers

-->> GCP - Block Storage and File Storage

- Block Storage:
- i. Persistent Disks: Network Block Storage
- Zonal: Data replicated in one zone
- Regional: Data replicated in multiple zone
 - ii. Local SSDs: Local Block Storage

NOTE: Configure it in Boot Disk, You can add new disks in networking, disks,
security, management
NOTE: You can also add existing disk
NOTE: Some machine types allow addition of local SSD

- File Storage:
- Filestore: High performance file storage

>> File store >> Enable API >> Create Instance

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> GCP - Block Storage

- Two popular types of block storage can be attached to VM instances:

- Local SSDs
- Persistent Disks

- Local SSDs are physically attached to the host of the VM instance

- Temporary Data
- Lifecycle tied to VM instance

- Persistent Disks are network storage

- More durable
- Lifecycle NOT tied to VM instance(can be attached to other VM)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Local SSDs

- Physically attached to the host of VM instance:

- Provide very high (IOPS) and low latency

- (BUT) Ephemeral Storage: Temporary Data(Data persists only until instance

is running)
- Enable live migration for data to survive maintenance events

- Data automatically encrypted

- HOWEVER, you CANNOT configure encryption keys!

- Lifecycle tied to VM instance

- ONLY some machine types support local SSDs

- REMEMBER:

- Choose NVMe-enabled and multi-queue SCSI images for best performance

- Larger Local SSDs (more storage), More vCPUs (attached to VM) => Even
better performance
-->> Local SSDs - Advantages and Disadvantages

- Advantages:

- Very Fast I/O (~10-100X Compared to PDs)

Very Fast throughput and lower latency

- Ideal for use cases needing high IOPs while storing temporary information
Examples: Caches, temporary data, scratch files etc

- Disadvantage:

- Ephemeral Storage
Lower Durability, Lower Availability , Lower Flexibility compared
to PDs

- you CANNOT detach and attach it another VM instance

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Persistent Disk (PD)

- Network Block Storage attached to your VM instance

- Provisioned Capacity

- Very Flexible:

- Increase size when you need it: when attached to VM instance

- Performance scales with size

For higher performance, resize or add more PDs

- Independent lifecycle from VM instance

- Attach/Detach from one VM instance to another

- Options: Regional and Zonal

- Zonal PDs replicated in single zone. Regional PDs replicated in 2 zones in
same region
- Typically regional PDs are 2x the cost of Zonal PDs

- Use case: Run your custom DB

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Persistent Disk vs Local SSDs

Feature Persistent Disks

Local SSDs

- 1. Attachment to VM Instance As a network

drive Physically Attached
- 2. Lifecycle Separate from VM
instance Tied with VM instance

- 3. I/O Speed Lower (network

latency) 10-100X of PDs

- 4. Snapshots Supported
Not Supported

- 5. Use Case Permanent Storage

Ephemeral Storage

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Types of SSD - Standard vs Balanced vs SSD

Feature Standard
Balanced SSD

- 1. Underlying Storage Hard Disk Drive

Solid State Drive Solid State Drive

- 2. Referred to as pd-standard
pd-balanced pd-ssd

- 3. Performance - Sequential IOPS Good

Good Very Good
(Big Data/Breach)

- 4. Performance - Random IOPS Bad

Good Very Good
(Transactional Apps)

- 5. Cost Cheapest
In Between Expensive

- 6. Use Cases Big Data

Balanced Between cost High Performance
(Cost Effective)
and performance

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Persistent Disk - Snapshots

- Take point-in-time snapshots of your persistent disk

- You can also schedule snapshots (configure a schedule)

- You can also auto-delete snapshots after X days
- Snapshots can be Multi-Regional and Regional

- You can share snapshots across projects

- You can create new disk and instance from snapshots

- Snapshots are incremental:

- Deleting a snapshot only deletes data which is NOT needed by other
snapshots

- Keep similar data together on a Persistent Disk:

- Separate your OS, volatile data and permanent data
- Attach multiple disks if needed
- This helps us to better organize your snapshots and images

-->> RECOMMENDATION

- If you are storing data, always use it for permanent data

- Avoid taking snapshots more often than once an hour

- Disk volume is available for use but “Snapshot reduces performance”

- (RECOMMENDED) Schedule snapshots during off-peak hours

- Creating snapshots from disk is faster than creating from images:

- But creating disks from image is faster than creating from snapshot
- (RECOMMENDED) If you are repeatedly create disks from a snapshot:
- Create an image from snapshot and use this image to create
disks

- Snapshots are incremental

- BUT you don not lose data by deleting older snapshots
- Deleting a snapshot only deletes data which is NOT needed by other
snapshots
- (RECOMMENDED) Do not hesitate to delete unnecessary snapshots.

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Playing with Persistent Disk

>> Create a VM instance >> Management, Security, Disks >> Add Disk >> Create

>> Disks >> Persistent-Disk

NOTE: If you terminate a VM then automatically the persistent disk also perishes.
To avoid that use the following steps:

>> New Instance >> Disk >> Boot Disk >> Advance >> Keep Boot Disk
>> Existing VM >> Edit >> Boot Disk >> Advance >> Keep Boot Disk

--> Creating a Snapshot

>> Disk >> Click the three dots next to any of the persistent disk >> Create
Snapshot >> Name >> Create

NOTE: You can use this snapshot to create a VM instance as it contains the Boot-
Disk Configuration

>> Disks >> Create >> Select a Source >> Disk from snapshot

** -->> To schedule snapshot

>> Schedule Snapshot >> Frequency >> Start Time >> Set Autodelete >> Create >>
Disks >> Select a disk >> edit >> snapshot schedule

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Playing with Machine Images

- (REMEMBER) Machine Images is different from Images

- Multiple Disks can be attached with a VM:

- One Boot Disk (Your OS runs from Boot Disk)
- Multiple Data Disks

- An image is created from the boot persistent disk

- HOWEVER, a Machine Image is created from a VM instance:

- Machine Image contains everything you need to create a VM instance:
- Configuration
- Metadata
- Permissions
- Data from one or more disks

- Recommended for disk backups, instance cloning and replication

>> Click on three dots next to a VM instance >> Create VM Image >> Set up >> Create

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Comparison

Scenarios Machine Image Persistent Disk

Snapshot Custom Image Instance Template

1. Single Disk Backup Yes Yes

Yes No

2. Multiple Disk Backup Yes No

No No
3. Differential Backup Yes Yes
No No

4. Instance Cloning and Replication Yes No

Yes Yes

5. VM Instance Configuration Yes No

No Yes

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Playing with Disks

- gcloud compute disks list/create/delete/resize/snapshot

- gcloud compute disks create DISK_NAME --zone=us-east1-a

- What should be the size and type?
--size=SIZE(1GB or 2TB)
--type=TYPE(default -pd-standard) (gcloud compute disk-types
list)

- What should be on the disk ?

--image --image-family --source-disk --source-snapshot

- How should data on the disk be encrypted

--kms-key --kms-project

- gcloud compute disks resize DISK_NAME --size=6TB

- (NOTE) Only increasing disk size is supported

- gcloud compute disks snapshot DISK_NAME --zone=us-central1-a --snapshot-

names=snapshot-test
- You can also play with the snapshots which are created:
gcloud compute snapshots list/describe/delete

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Playing with Images

- gcloud compute image

- Actions: create/delete/deprecate/describe/export/import/list/update
- Creating Images
- gcloud compute images create IMAGE_NAME
- From Disk: gcloud compute images create IMAGE_NAME --
source-disk DISK_NAME --source-disk-zone DISK_ZONE
- From a snapshot: gcloud compute images create IMAGE_NAME
--source-snapshot SNAPSHOT_NAME
- From another image: gcloud compute images create
NEW_IMAGE_NAME --source-image SOURCE_IMAGE_NAME --source-image-project
SOURCE_IMAGE_PROJECT
 - From latest non deprecated image from a family: --
source-image-family=source-image-family --source-image-project=source-image-
project

- Deprecated Image
- gcloud compute images deprecate IMAGE --state=DEPRECATED

- Exports virtual disk images

- gcloud compute images export --image=my-image --destination-
uri=gs://my-bucket/my-image.vmdk --export-format=vmdk --project=my-project

- Other Examples:
- gcloud compute images delete my-image1 my-image2

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Storage - Scenarios - Persistent Disk

- 1. You want to improve performance of persistent disks(PD)

- Increase size of PD or Add more PDs. Increase vCPUs in your VM

- 2. You want to increase durability of Persistent Disks(PD)

- Go for Regional PDs (2X cost but replicated in 2 zones)

- 3. You want to take hourly backup of Persistent Disk for DR

- Schedule hourly snapshots!

- 4. You want to delete old snapshot created by scheduled snapshots

- Configure it as part of your snapshot scheduling

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Cloud Filestore

- Shared cloud file storage:

- supports NFSv3 protocol
- Provisioned Capacity

- Suitable for high performance workloads

- Up to 320 TB throughput of 16GB/s and 480K IOPS

- Supports HDD (general purpose) and SSD

(performance-critical workloads)

- Use cases: file share, media workflows and content management

>> Filestore >> Enable Filestore API >> Create Instance

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Review - Global, Regional and Zonal Resources

1. Global

i. Images
ii. Snapshots
iii. Instance Templates (Unless you use zonal resources in your template)

2. Regional

i. Regional managed instance groups

ii. Regional persistent disks

3. Zonal

i. Zonal managed Instance groups

ii. Instance
iii. Persistent Disks
You can attach disk only to instances in the same zone as the disk

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Storage Scenarios

- 1. You want very high IOPS but your data can be lost without a problem

- Local SSDs

- 2. You want to create a high performance file sharing system in GCP which can be
attached with multiple VMS

- Filestore

- 3. You want to backup your VM configuration along with all of its attached
Persistent Disks

- Create a Machine Image

- 4. You want to make it easy to launch VMs with hardened OS and customized
software

- Create a Custom Image

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================
 Object Storage - Cloud
Storage

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

** Download the course file provided in the course

-->> Demo

>> Cloud Storage >> create bucket >> Name(Must be unique globally) >> Region/Dual-
Region/Multi-Region >> Choose storage class >> Create

NOTE: We have not specified the size

>> Drag n Drop the files (2030, cloud....) into the bucket

- Cloud Storage is the Object Storage option in GCP

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Cloud Storage

- Most popular, very flexible and inexpensive storage device

- Serverless: Autoscaling and Infinite Scale

- Store large objects using a key-value approach:

- Treats entire objects as a unit (Partial updates not allowed) (It means
that you can update a object fully)
- Recommended when you operate on entire object most of the time
- Access control at Object level
- Also called Object Storage

NOTE: If you open an object (Say a image here, which is an object) you can find the
URI which is the Key and object itself is a value

- Provides REST API to access and modify objects

- Also provides CLI (gsutil - google storage) and Client Libraries (C++, C#,
Java, Node.js, PHP, Python and Ruby)

- Store all file types - text, binary, backup, and archives

- Media files and archives, Application, packages and logs
- Backups of your databases or storage devices
- Staging data during on-premise to cloud database migration

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------
-->> Cloud Storage - Objects and Buckets

- Objects are stored in buckets

- Bucket names are globally unique
- Bucket names are used as part of objects URLs => Can contain ONLY lower case
letters, numbers, hyphens, underscore, and periods
- 3-63 characters max. Can’t start with “goog” prefix or should not contain
“google” (even misspelled)
- Unlimited objects in a bucket
- Each bucket is associated with a project

- Each object is identified by a unique key

- Key is unique in a bucket

- Max object size is 5TB

- But you can store unlimited number of such objects.

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Cloud Storage - Storage Classes - Introduction

- Different kinds of data can be stored in Cloud Storage

- Media files and archives
- Application packages and logs
- Backups of your databases and storage devices
- Long term archives

- Huge variations in access patterns

- Can I pay a cheap price for objects I access less frequently

- Storage classes help to optimize your costs based on your access needs
- Designed for durability of 99.99999999999% (11 9’s)

-->> Storage Classes Comparison

- i. Standard
ii. Nearline Storage
iii. Coldline Storage
iv. Archive Storage

Storage Class Name Minimum Storage Total

Monthly Availability Use Case
Duration

- Standard STANDARD None

>=99.95% in multi region and dual region Frequently used data/short

>=99.99% in regions period of time

- Nearline Storage NEARLINE 30 days
>=99.99% in multi region and dual region, Read or modify once a month on
>=99.0%
% in regions average

- Coldline Storage COLDLINE 90 days

>=99.99% in multi region and dual region Read or modify at most once a
>=99.0%
in regions quarter

- Archive Storage ARCHIVE 365 days 99.99%

in multi region and dual region Less than once a year
>=99.0%
in regions

NOTE: You can configure default class for storage but you can specify storage class
at object level
NOTE: You can have objects with different classes at different level in same Bucket
NOTE: Default class will be assigned if an object is not specified a class

-->> Feature

- Low Latency (first byte typically in tens of milliseconds)

- Unlimited storage
- Autoscaling (No configuration needed)
- No minimum object size

- Same APIs across storage classes

- Committed SLA is 99.95% for multi region and 99.99% for single region for
Standard, Nearline, and Coldline Storage classes
- No committed SLA for Archive Storage

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Cloud Storage - Uploading and Downloading Objects

1. Upload

- i. Simple Upload

- Small files (that can be re uploaded in case of failures) + NO object

metadata

- ii. Multipart upload

- Small files (that can be re uploaded in case of failures) + object

metadata

- iii. Resumable Upload

 - Larger files. RECOMMENDED for most use-cases (even for small files. Costs
additional HTTP request)

- iv. Streaming transfers

- Upload an object of known size

- v. Parallel composite uploads

- File divided up to 32 chunks and uploads in parallel. *Significantly

faster if network and disk speed are not limiting factors

2. Download

- i. Simple Download

- Downloading objects to a destination

- ii. Streaming Download

- Downloading data to a process

- iii. Sliced Object Download

- Slice and download large objects

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Object Versioning

- Prevents accidental deletion and provides history

- Enabled at bucket level
- Can be turned on/off at any time

- Live version is the latest version

- If you delete live object, it becomes noncurrent object version
- If you delete noncurrent object version, it is deleted

NOTE: The concurrent version is a copy of deleted live version

NOTE: If the concurrent version is deleted then the object is entirely deleted

- Older versions are uniquely identified by object key + a generation number)

- Reduce costs by deleting older (noncurrent) versions

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Object Lifecycle Management

- Files are frequently accessed when they are created

 - Generally usage reduces with time
- How do you save costs by moving files automatically between storage
classes ?

- Identify objects using conditions based on:

- Age, CreatedBefore, IsLive, MatchesStorageClass, NumberOfNewerVersions etc
- Set multiple conditions: all conditions must be satisfied for action to
happen

- Two kinds of actions:

- SetStorgaeClass actions (change from one storage class to another), this is
used in scenarios where the file is accessed less as time
- Deletion actions (delete objects), delete an object after certain time
period

- Allowed Transitions
- (Standard or Multi-Regional) to (Nearline or Coldline or Archive)
- Nearline to (Coldline to Archive)

>> Rule:

{
“Lifecycle”: {
“rule”: [
{
“action”: {”type” : “delete”}, -->> Deletes an object if not
used for 30 days
“condition”: {
“age”: 30,
“isLive”: true
}
},
{
“action”: {
“type”: “SetStorageClass”,
“StorageClass”: “NEARLINE”,
},
“condition”: {
“age”: 365,
“matchesStoageClass”: {“STANDARD”},
}
}
}
}
}

>> Cloud Storage >> Bucket >> Lifecycle >> Manage Lifecycle

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Cloud Storage - Encryption

- Cloud Storage always encrypts data on the server side

- Configure Server-Side encryption: Encryption performed by cloud storage

- Google-Managed encryption key: Default (No configuration required)

- Customer-managed encryption keys: Created using “Cloud KMS”

- Cloud Storage Service Account should have access to keys in
KMS for encrypting and decrypting using the Customer-Managed encryption key

- (OPTIONAL) Client-side encryption

- GCP does NOT know about the keys used

>> Demo: Server side encryption

>> Open the bucket >> Configuration >> Encryption Type >> Google Managed
Key/Customer Managed Encryption key

>> Create Bucket >> Advanced Setting >> Encryption

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Cloud Storage - Scenarios

- 1. How do you speed up large uploads (example 100GB) to cloud storage?

- Use “Parallel composite uploads” (File is broken in to small chunks

and uploaded)

- 2. You want to permanently store application for regulatory reasons. You do not
expect to access them at all.

- Cloud Storage - Archive

- 3. Log files stored in Cloud Storage. You expect to access them once in a
quarter.

- Cold Line

- 4. How do you change storage class of an existing bucket in Cloud Storage

- Step 1: Change default storage class of the bucket

Step 2: Update the Storage Class of the objects in the bucket

>> Bucket >> Configuration >> Change Bucket Class

>> You can add metadata for an object

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------
-->> Cloud Storage - Command Line - gsutil

- (REMEMBER) gsutil is the CLI for Cloud Storage (NOT gcloud)

- Cloud Storage (gsutil)

- gsutil mb gs://BKT_NAME (Create Cloud Storage Bucket)

- gsutil ls -a gs://BKT_NAME (List current and non-current object versions)

- gsutil cp gs://SRC_BKT/SRC_OBJ gs://DESTN_BKT/NAME_COPY (Copy Objects)

- o ‘GSUtil:encryption_key=ENCRYPTION_KEY’ - Encrypt Object

- gsutil mv (Rename/Move Objects)

- gsutil mv gs://BKT_NAME/OLD_OBJ_NAME gs://BKT_NAME/NEW_OBJ_NAME
- gsutil mv gs://OLD_BKT_NAME/OLD_OBJECT_NAME
gs://NEW_BKT_NAME/NEW_OBJ_NAME

- gsutil rewrite -s STORAGE_CLASS gs://BKT_NAME/OBJ_PATH (Ex: Change Storage Class

for objects)

- gsutil cp: Upload and Download Objects

- gsutil cp LOCAL_LOCATION gs://DESTINATION_BKT_NAME/ -- (Upload)
- gsutil cp gs://BKT_NAME/OBJ_PATH LOCAL_LOCATIN -- (Download)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Cloud Storage - Command Line - gsutil - 2

- Cloud Storage (gsutil)

- gsutil versioning set on/off gs://BKT_NAME (Enable/Disable Versioning)

- gsutil uniformbucketlevelaccess set on/off gs://BKT_NAME

- gsutil acl ch (Set Access Permissions for Specific Objects)

- gsutil acl ch -u AllUsers:R gs://BKT_NAME/OBJ_PATH (Make specific
object public)

- gsutil acl ch -u john.doe@example.com:WRITE gs://BKT_NAME/OBJ_PATH

- Permission -READ (R), WRITE (W), OWNER (O)
- Scope - User, allAuthenticatedUsers, allUsers (-u), Group (-
g), Project (-p) etc

- gsutil acl set JSON_FILE gs://BKT_NAME

- gsutil iam ch MBR-TYPE:MBR_NAME:IAM_ROLE gs://BKT_NAME (Setup IAM role)

- gsutil iam ch user:me@myemail.com:objectCreator gs://BKT_NAME

- gsutil iam ch allUsers:ObjectViewers gs://BKT_NAME (make the entire

bucket readable)
- gsutil signurl -d 10m YOUR_KEY gs://BUCKET_NAME/OBJECT_PATH (Signed URL for
temporary access)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================

Authentication and
Authorization in GCP (IAM)

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Identity Access Management - IAM

- You have resources in the cloud (examples - a virtual server, a database etc)

- You have identities (human and non-human) that need to access those resources and
perform actions
- For example: launch (stop, start, or terminate) a virtual server

- How do you identify users in the cloud

- How do you configure resources they can access?
- How can you configure what actions to allow?

- In GCP, Cloud IAM provides the service

- Authentication (is it the right user?) and

- Authorization (do they have the right access?)

- Identities can be
- A GCP User (Google Account or Externally Authenticated User)
- A Group of GCP user
- An application running in GCP
- An application running in your database center
- Unauthenticated users

- Provides very granular control

- Limit a single user:
- to perform single action
- on a specific cloud resource
- from a specific IP
- running a specific time window

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Cloud IAM - Examples

- I want to provide access to manage a specific cloud storage to a colleague of
mine:

- Important Generic Concepts:

- Member: My Colleague
- Resource: Specific Cloud Storage Bucket
- Action: Upload/Delete Objects

- In Google Cloud IAM:

- Roles: A set of permissions (to perform specific actions on
specific resources)
- Roles do NOT know about members. It is all about
permissions

- How do you assign permissions to a member?

- Policy: You assign (or bind) a role to a member

- 1: Choose a role with right permissions (Ex: Storage Object Admin)

2: Create Policy binding member (your friend) with role (permissions)

- IAM in AWS is very different from GCP

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> Roles - IAM

- Roles are Permissions:

- Perform some set of actions on some set of resources

- Three Types:

- Basic Roles (or Primitive roles) - Owner/Editor/Viewer

- Viewer (roles.viewer): Read-only actions
- Editor (roles.editor): Viewer + Edit actions
- Owner (roles.owner): Editor + Manage Roles and Permissions +
Billing
- EARLIEST VERSION: Created before IAM
- NOT RECOMMENDED: Do not use this in production

- Predefined Roles: Fie grained roles predefined and managed by google

- Different roles for different purposes
- Examples: Storage Admin, Storage Object Admin, Storage Object
Viewer, Storage Object Creator

- Custom Roles: When predefined roles are NOT sufficient, you can create
your own custom roles

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Playing with Roles

>> Search Roles >> Filter Name: roles/viewer >> viewer

>> Roles >> Create Role >> Fill the permissions

- Important Cloud Storage Roles:

- Storage Admin (roles/storage.admin)

- storage.buckets.*
- storage.objects.*

- Storage Object Admin (roles/storage.objectAdmin)

- storage.objects.*

- Storage Object Creator (roles/storage.objectCreator)

- storage.object.create

- Storage Object Viewer (roles/storage.objectViewer)

- storage.objects.get
- storage.objects.list

- All four roles have these permissions:

- resourcemanager.projects.get
- resourcemanager.projects.list

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Important Concepts - IAM

- Member: Who?

- Roles: Permissions (What Actions? What Resources?)

- Policy: Assign Permissions to Members

- Map Roles (What?), Members (Who?), and Conditions (Which Resource?,

When? From Where?)

- Remember: Permissions are NOT directly assigned to Members

- Permissions are represented through Role
- Member gets permissions through Role

- A role can have multiple permissions

- You can assign multiple roles to a Member

-->> IAM Policy

- Roles are assigned to users through IAM policy

- Represented by a Policy Object
- A policy object has list of bindings
- A binding, binds a role to list of members

- Member type is identified by prefix:

- Ex: user, serviceaccount, group, or domain

Permissions >> Role >> User >> Bindings >> group

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

--> DEMO - IAM

>> Search >> IAM >> Add >> Member >> Email/ID >> Assign Role

NOTE: Member is also called Principal or Identity

>> Policy Troubleshooter >> Enter ID >> Select project in Suggestions >> enter
permission to check >> add more

-->> IAM commands

- gcloud: Playing with IAM

- “gcloud compute project-info describe”: Describe current project

- “gcloud auth login”: Access the cloud platform with google user
credentials
- “gcloud auth revoke”: Revoke access credentials for an account
- “gcloud auth list” - List all active accounts

- gcloud projects
- “gcloud projects add-iam-policy-binding”: Add IAM policy binding
- “gcloud projects get-iam-policy”: Get IAM policy for a project
- “gcloud projects remove-iam-policy-binding”: Remove IAM policy
binding
- “gcloud projects set-iam-policy”: Set the IAM policy
- “ gcloud projects delete”: Delete a project

- gcloud iam
- “gcloud iam roles describe”: Describe an IAM role
- “gcloud iam roles create”: create an iam role (--project, --
permissions, --stage)
- “gcloud iam roles copy”: Copy an IAM role

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------
-->> Service Accounts

- Act as a decoy of user/admin

- Scenario: An application on a VM needs access to cloud storage

- You do not want to use personal credentials to allow access

- (RECOMMENDED) Use Service Accounts

- Identified by an email address (EX: id-

compute@developer.gserviceaccount.com)
- Does NOT have password:
- Has a private/public RSA key-pairs
- Can’t login via browsers or cookies

- Service Account Types:

1. Default Service Account: Automatically created when some services are

used
- (NOT RECOMMENDED): Has Editor role by default

2. User Managed: User Created

- (RECOMMENDED) Provides fine grained access control

3. Google-managed service accounts: Created and managed by Google

- Used by GCP to perform operations on user’s behalf
- In general we do not need to worry about them

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Service Accounts

- 1. Use Case: Say you want to link a cloud storage bucket to a VM

>> Service Accounts >> Create Service Account >> Name >> Create >> Grant
permissions >> Continue >> Grant users access to this service account

>> VM >> Add VM Instance >> Specify a service account >> Create >> SSH >> create a
bucket >> gsutil mb gs://BUCKET_NAME >> Access Denied Error >> Edit the
role/permission for the service account >> choose cloud storage (GCS)

NOTE: You can use the service account for a VM to restrict the permissions of users
using it (say if you do not want any user to assign a bucket to the VM
you can describe that in your service account)

NOTE: In Service Accounts there are no passwords involved

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Scenarios
-> 1. Use Case 1: VM <--> Cloud Storage

- i. Create a Service Account Role with the right permissions

- ii. Assign a Service Account role to VM instance

- Uses Google Cloud-managed keys:

- Key generation and use are automatically handled by IAM when we assign a
service account to the instance
- Automatically rotated
- No need to store credentials in config files

- Do NOT delete service accounts used by running instances:

- Application running on those instance will lose access

-> 2. Use Case 2: On Prem <--> Cloud Storage (Long Lived)

- You CANNOT assign Service Account directly to an on Prem App

- i. Create a Service Account with right permissions

ii. Create a Service Account User Managed Key

>> Service Account >> Select an Account >> Keys >> Select the key in
JSON/P12 format
- “gcloud iam service-accounts keys create”
- Download the service account key file
- Keep it secure (it can be used to impersonate service
account)

iii. Make the Service Account Key File Accessible to your application
- Set environmental variable GOOGLE_APPLICATION_CREDENTIALS
export GOOGLE_APPLICATION_CREDENTIALS=”/PATH_TO_THE_KEY_FILE”

iv. Use Google Cloud Client Libraries

- Google cloud libraries use a library -Application Default
Credentials(ADC)
- ADC uses the service account key file if env var
GOOGLE_APPLICATIO_CREDENTIALS exists!

NOTE: It is always recommended to change the key once in a while

-> 3. On Prem <--> Google Cloud APs (Short Lived)

- Make calls from outside GCP to Google APIs with short lived permissions
- Few hours or shorter
Less risk compared to sharing service account keys!

- Credential Types:

- OAuth 2.0 access Tokens

- OpenID connect ID tokens
- Self-signed JSON web tokens (JWTs)

- Example

- When a member needs elevated permissions, he can assume the service account
role (Create OAuth 2.0 access token for service account)
- OpenID Connect ID tokens is recommended for service to service authentications:
 - A service in GCP needs to authenticate itself to a service in other
cloud.

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Scenarios with Service Accounts

- 1. Application on a VM wants to talk to a Cloud Storage Bucket and wants to put a

message on Pub Sub Topics

- Configure the VM to use a Service Account with right permissions

- 2. Is Service Account an Identity or a resource

- It is both. You can attack roles with Service Account (Identity). You
can let other members access a SA by granting them a role on the Service
Account (resource)

- 3. VM instance with default service account in Project A needs to access Cloud

Storage Bucket in Project B

- In project B, add the service account from Project A and assign

Storage Object Viewer Permission on the bucket

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Access Control Lists (ACL)

- ACL: Define who has access to your buckets and objects, as well as what level of
access they have

- How it is different from IAM?

- IAM permissions apply to all objects within a bucket
- ACLs can be used to customized specific access to different objects

- User gets access if he is allowed by either IAM or ACL?

- (REMEMBER) Use IAM for common permissions to all objects in a bucket

- (REMEMBER) Use ACLs if you need to customize access to individual objects

-->> OVERVIEW & DEMO

- How do you control access to objects in a Cloud Storage Bucket?

- Two types of access controls:

- Uniform (Recommended): uniform bucket level access using IAM

 - Fine Grained: Use IAM and ACLs to control access
Both bucket level and individual object level permission

- Use uniform access when all users have same level of access across all objects in
a bucket

- Fine grained access with ACLs can be used when you need to customize the access
to an object level

>> Cloud Storage >> Pick a bucket >> Permissions >> Access Control >> Fine
Grained/Uniform >> Switch to uniform

>> Object >> Edit Permission

NOTE: If you are using uniform level access, you cannot have ACL at objects level

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Cloud Storage - Signed URL

- You would want to allow a user limited time access to your objects:
- Users do NOT need Google accounts

- Use Signed URL Functionality

- A URL that gives permission for limited time duration to perform specific
actions

- How to create a Signed URL

1. Create a Key (YOUR_KEY) for the Service Account/User with desired

permissions
2. Create Signed URL with the key
- gsutil signurl -d 10m YOUR_KEY gs://BUCKET_NAME/OBJECT_PATH

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Exposing a Static Website - Cloud Storage

- 1. Create a bucket with the name as website name (Name of the bucket should match
DNS name of the website)
- Verify the domain is used by you

- 2. Copy the files to the bucket

- Add index and error html files for better user experience

- 3. Add member allUser and grant Storage Object Viewer option

- Select Allow Public Access
-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

===================================================================================
=========================================================================

Database in GP

-----------------------------------------------------------------------------------
-------------------------------------------------------------------------

-->> Database Fundamentals

- Databases provide organized and persistent storage for your data

- To choose between different database types, we would need to understand

- Availability
- Durability
- RTO
- RPO
- Consistency
- Transactions

-->> Recovery Point Objective (RPO) and Recovery Time Objective (RTO)

- RPO: Time Period until data loss is accepted

RTO: Time period until downtime is accepted

-->> Achieving RTO and RPO - Failover Examples

- 1. Very Small data loss (RPO - 1 minute)

Very Small downtime (RTO - 5 minutes)

- Hot Standby: Automatically synchronize data. Have a standby automatically

ready to pickup load. Use automatic failover from master to standby

- 2. Very Small data loss (RPO - 1 minute)

But I can tolerate some downtime (RTO - 15minutes)

- Warm Standby: Automatically synchronize data. Have a standby with minimum

infrastructure. Scale it up when a failure happens

- 3. Data is critical (RPO - 1 minute) but I can tolerate downtime of a few hours
(RTO - few hours)

- Create regular data snapshots and transaction logs. Create database from
snapshots and transaction logs when a failure happens
- 4. Data can be lost without a problem (for example: cached data)

- Failover to a completely new server