Let's start from the basics.
Why should one move to the cloud?
The answer is simple:
- Low Latency
- High Availability
- Go Global in minutes
What does the above imply?
If you application is deployed on a server, it has high latency (if accessed from all over the world) and has low availability (if there is a crash).
Cloud provides an option for users to deploy their applications over virtual servers which can be deployed over various region (and hence high availability) + accessible (low latency).
Google cloud has 24 regions (as we write) and 73 zones spread over 17 countries.
What is a Region? What is a Zone?
Region is like a data center in a location. Zones are within a Region. For Google Cloud, each region has a minimum of 3 zones.
- High Availability + Fault Tolerance within a region.
- Each zone has 1 or more cluster
- Cluster is a physical hardware (within a DC)
- Zones are connected to each other via low latency links.
How to deploy applications on Google Cloud?
Deploy Applications on VMs.
- Deploy Multiple VMs using Instance Groups
- Add a Load balancer
To deploy VMs, we use the Google Compute Engine.
We use the Compute Engine to:
- Create and manage the lifecycle of VMs
- Lifecycle implies create, start, stop, run and delete
- For multiple VMs, deploy a Load Balancer
- For multiple VMs, configure Auto Scaling.
- Attaching Storage to a VM
- Attaching Network connectivity like IP address (static) and configurations of VMs (like the HW etc)
See below pics on how to start a VM (for beginners).
Configuring/Creating a VM:
Note that every VM has:
- An internal IP (which is fixed and never changes)
- An external IP
- Used to access from external network
- This IP is ephemeral (implies once we restart the VM, the IP changes)
- How can then one access the VM if IP keeps changing?
- Use a static IP. (Its a permanent external IP)
- Note: Static IP is charged even when not in use.
Isn't creating VMs manually very tedious?
Yes!! Especially if you want to create large # of VMs.
Thus, one can use
- Startup scripts
- Scripts to be run on startup.
- Instance template
- As the name suggests, it's a template which will have all the configurations one needs in a VM.
- Note: One cannot update an instance. You would need to create a copy and edit/modify.
- You can then launch VMs using an Instance Template.
- Custom Image with OS packages and softwares installed
- Every time we create a VM instance, OS patches and softwares need to be installed.
- This issue is eliminated by using a Custom Image (which has the OS and SW pre-installed)
- Create an instance template to use a custom image.
Pre-emptible VMs:
If your application:
- Does not need VMs immediately (batch jobs)
- Are Fault Tolerant (can be restarted anytime)
one can opt for pre-emptive VMs. These are similar to On-Spot VMs in AWS.
Very very cost effective.
They can be shut down at any time by giving a 30 sec warning by Google Cloud.
Note: They cannot be restarted.
They are used to save costs and for applications where there is no immediate need for a VM.
But what if cost is not the important criteria but one has constraints like No shared Host for a VM?
We all know that on a single host in the cloud, if we have multiple VMs hosted, these VMs could belong to different folks. Such shared hosts reduce costs. However, there may be a requirement to use a dedicated host. Note that the default config is shared.
What is a dedicated host?
A host where all the deployed VMs belong to a certain company/individual etc.
How is this achieved?
By creating VMs on dedicated host (with Sole Tenant Nodes)
There is an option for customized machine types where you can choose the memory, GBU and vCPUs.
Only valid for E2, N2 and N1 machine types.
Billing is based on per vCPU and memory provisioned. (hourly charges)
We discussed about creating VMs and machine types etc.
We also know that we can create a group of VM instances by using an Instance group.
Instance Groups are classified as "Managed" and "UnManaged"
Managed Instance Groups (MIG) manage similar instances of VMs (identical using templates). Auto scaling, Automatic removal and replacement of VM due to its health etc are some of the features for MIG.
Note -
. Instance template is mandatory and create instance groups using it.
. Default auto scaling used is CPU Utilization (60%)
UnManaged Instance Group as the name suggests, manages different configuration of VMs and the features like auto scaling etc are not available.
We now have multiple VM instances created using an instance templated and part of an instance group (managed). We also have an auto scaling + health policy in place. What are we missing? Traffic handling aka Load Balancer (Global > distributes load across VMs in different regions).
Go to Network Services > Load Balancing.
Load Balancing options:
