#1 GCP Professional Cloud Architect – getting started
If you’re completely new to Google Cloud (I’m assuming you know what it is ) you’ll need to create an account, and at the time of writing this, well for all the time I’ve known – you’ll get $300 of free credit when you sign up for GCP.
Head over to cloud.google.com and log in with your gmail account, you should then be able to claim your $300 credit.
Google provides a good overview of GCP here, let’s break it down a little.
Google provides a whole host of services to users hosted in the cloud, and those services can be thought of as anything you’d ever need in IT Hardware (Computers, HDDs etc.) or resources such as computer instances, load balancers, Virtual Private Clouds etc. These are all hosted in Google’s data centres around the globe.
Why use the cloud?
In simple terms it saves you having to run, maintain and scale your own data centres and hardware.
If you’re a business and need to run a web server to host an application your staff use, you also need a database, email server, firewall and online document storage – that’s a lot of hardware to house. With the way the market is thanks to Covid, what happens if after you’ve spent thousands on your IT infrastructure you lose 2 two-thirds of your business overnight? That’s a lot of expenditure for a business operating a a smaller scale. Conversely, imagine your business ramps up and your workforce doubles, you may need to add to the infrastructure and house twice as much kit… and then there’s the lead time of getting it scoped, ordered, delivered, installed, configured and working – this could be months!
Cloud offers pretty much a pay as you go model whereby if you need a web server, you can pay for a web server. If your traffic doubles overnight, you scale it accordingly, pretty much instantly! If you launch in a new country, deploy the application to that region and cache the database to save you running 2 separate databases, or run 2 separate databases if you need to! The flexibility is there, and you only pay for what you use… and if business does drop, just scale back!
Regions & Zones
These data centres are in REGIONS and Google has a number of regions scattered throughout Asia, Australia, Europe, North America, and South America.
In each region there are a number of ZONES, however these zones are ISOLATED from each other within their region. This means that if one zone goes down for whatever reason, the tasks being performed can be pushed to another zone within that region. It’s a different story if a region goes down, but I’m sure Google will explain how that handle that issue at some point.
The name for each zone is made up of that Region, the zone name and a letter, e.g.asia-east1-a
Having a Regional Zone set up allows applications to be located close to the clients, and end users – which reduces latency (the time spent sending and receiving data between user & application).
Zones have high-bandwidth, low-latency network connections, which means applications can exchange a lot of data very quickly if they’re in the same Zone.
It’s considered best practice to deploy your application across numerous zones and regions to ensure it has high availability and is resistant to faults (fault-tolerant). Operating this way helps protect against resources failing and as if a problem does occur your application is still available in another zone, as if a zone becomes unavailable, all resources in that zone will be down until restored.
RESOURCES
Anything you think of as software or hardware in computing terms is called a RESOURCE in GCP. Here’s a list of everything Google offers, and the list keeps growing! You can choose only the services you need, when you need them and you only pay for what you use.
Resource Availability
How resources integrate with each other is different depending on the resource, some can only be accesses by other resources in a certain zone, others within a region and some are global.
Zones have high-bandwidth, low-latency network connections to other zones in the same region. As a best practice, Google suggests deploying applications across numerous zones and multiple regions so users can deploy high availability, fault-tolerant applications. This is a key step as it helps protect against unexpected failures of components. Within a Zone, you will find zonal resources that operate within a single zone. If a zone becomes unavailable, all zonal resources in that zone are unavailable until service is restored.
Global Resources
| Global Resources | Accessible by any resource in any zone within the same project. When you create a global resource, you don’t need to provide a scope specification |
| Addresses | Reserved Global or Static IP Addresses, used for global load balancers: HTTP(S), SSL proxy, and TCP proxy. |
| Images | Used by any instance or disk resource in same project as image, preconfigured or bespoke. |
| Snapshots | Persistant snapshots available to disks in same project as snapshot |
| Instance Template | Used t create VM Instances & managed instance groups, can be defined & restricted as zonal resource |
| Firewalls | Apply to single VPC |
| Cloud Interconnects | Highly available connection from your premises to Google’s Network. Resource is global however attachments inside of connection are regional resources. |
| Global Operations | Operations on global resource are global operations, on regional resource are regional operations and on zone are zonal operations. |
Regional Resources
| Regional Resources | Accessible by any resources within the same region. |
| Addresses | Reserved regional static external IP addresses for your project. Static external IP addresses are a regional resource that are used by instances that are in the same region as the address, by regional forwarding rules for network load balancers, and for protocol forwarding. |
| Cloud Interconnect attachments | Allocates a VLAN on your Cloud Interconnect and connects it to a VPC network. Attachment is regional resource, Cloud Interconnect connection is global resource. |
| Regional Operations | performing an operation on a regional resource is considered a per-region operation. |
Zonal Resources
| Zonal Resources | unique to that zone and are only usable by other resources in the same zone |
| Instances | VM instance is located within a zone and can access global resources or resources within the same zone. |
| Persistent disks | Accessed by other instances within the same zone, can attach a disk only to instances in the same zone as the disk. |
| Machine types | Instances and disks can only use machine types that are in the same zone. |
PROJECTS
All resources you use must belong to a project. The project contains the settings, permissions, and other information about your applications.
Resources within a project integrate easily, e.g. by communicating through an internal network but a project can’t access another project’s resources unless you use Shared VPC or VPC Network Peering.
Each project you create has:
| Project Name | User provides this |
| Project ID | Google provides a default but user can edit – globally unique |
| Project Number | Google Provides |
* If you delete a project you can never use the Project ID again.
Each project is associated with one billing account but you can have resource usage from multiple projects billed to the same account.
A project serves as a namespace and every resource within each project must have a unique name, however you can reuse the names if in different projects…however some resource names must be globally unique.
Interacting with your resources
There are 3 ways you can work with Google Cloud
| Google Cloud Console – Graphical user interface |
| Command-line interface |
| Client libraries |
So how much does it all cost…
Here’s a price list and Google provides a pricing calculator also to scope out project costs.