Understanding virtual machines in the cloud

In this section, you will learn about Compute Engine in GCP and its major features. This includes the virtual machine types that are available in GCP, disk options, and encryption solutions. Moreover, this section will introduce Virtual Private Cloud and its main characteristics. Finally, we will look at Load Balancing, DNS, and CDN in GCP.

Google Compute Engine

IaaS in GCP is implemented with Compute Engine. Compute Engine allows users to run virtual machines in the cloud. The use cases for Compute Engine are as follows:

• Websites
• Legacy monolithic applications
• Custom databases
• Microsoft Windows applications

Compute Engine is a regional service where, when you deploy it, you must specify the instance name, the region, and the zone that the instance will run in. Note that the instance must be unique within the zone. GCP allows administrators to deploy Compute Engine VMs with the same name, so long as they stay in different zones. We will discuss this in more detail when we look at internal DNS.

There are four virtual machine family types that you can choose from:

• General-purpose: This category is for running generic workloads such as websites or customized databases.
• Compute-optimized: This category is for running specific heavy CPU workloads such as high-performance computing (HPC) or single-threaded applications.
• Memory-optimized: This category is for running specific heavy in-memory workloads such as large in-memory databases or in-memory analytics applications.
• GPU: This category is for running intensive workloads such as machine learning, graphics applications, or blockchain.

In the general-purpose category, you can choose between four different machine types, as illustrated in the following diagram:

Figure 1.17 – General-purpose Compute Engine machine types in GCP

To choose the appropriate machine type for your workload, let's have a look at the following table:

Each of the previous machine types can have different configurations in terms of vCPUs and memory. Here, you can select between predefined and custom machine types. Predefined machine types let you choose a Compute Engine instance that has a predefined amount of vCPUs and RAM. On the other hand, the custom machine type allows you to select the vCPUs and RAM that are required for your workload. You can have additional options for your predefined Compute Engine instance. You can run a virtual machine that shares a core with other users to save money, or you can choose an instance that has a different balance of vCPUs and memory.

We can summarize all the machine type configurations with the following diagram:

Figure 1.18 – Machine type configurations in GCP

Another important aspect of Compute Engine is its boot disk. Each virtual machine instance requires a boot disk to run properly. In the boot disk, the operating system is installed, as well as the main partition. The boot disk is a permanent storage disk and it can be built from several types of images. GCP offers pre-built public images for both Linux and Windows operating systems. Some of them are license free such as CentOS, Ubuntu, and Debian. Others are premium images, and they incur license fees.

Boot disks can be divided into three types:

• Standard persistent disk: This is a magnetic hard disk drive (HDD) that can have up to 7,500 IOPS in reading and 15,000 IOPS in writing operations.
• Balanced persistent disk: This is the entry-level solid-state drive (SSD) and can have up to 80,000 IOPS in both reading and writing operations
• SSD persistent disk: This is the second-level SSD and can have up to 100,000 IOPS in both reading and writing operations.

Boot disks are the primary disks for a Compute Engine instance. Additionally, you can attach more disks to your virtual machine if you need extra space or for extremely high performance. For the latter, you can add a local SSD as a secondary block storage disk. They are physically attached to the server that hosts your Compute Engine instance and can have up to 0.9/2.4 million IOPS in reading and 0.8/1.2 million IOPS in writing (with SCSI and NVMe technology, respectively).

Security is a particularly important feature when you design your Compute Engine instance. For this reason, Google lets you choose from three different encryption solutions that apply to all the persistent disks of your virtual machine, as follows:

• Google-managed key: This is the default encryption and it is enabled by default on all persistent disks. The encryption key is managed by Google and users do not have to worry about anything.
• Customer-managed key: With this encryption method, the data is encrypted with a user key that is periodically rotated via Google's Key Management System (KMS). This GCP-managed service allows users to have their encryption keys and manage them inside the user's project.
• Customer-supply key: With this encryption method, the data is encrypted with a user-supply key, which is stored and managed outside the GCP user's project.

In this section, you learned what options you have when you decide to run virtual machines on GCP. In the next section, you will be introduced to Virtual Private Cloud in GCP.

VPC overview

Virtual Private Cloud (VPC) is a virtualized private network and data center. Compute resources, storage, and load balancers live within VPC inside the Google Cloud production network that belongs to a specific project. VPC is powered by Andromeda (https://www.usenix.org/system/files/conference/nsdi18/nsdi18-dalton.pdf), the GCP network virtualization stack, which is fully distributed to avoid having a single point of failure. A VPC network provides the following:

• Connectivity services for interconnected Compute Engine, Google Kubernetes Engine (GKE) clusters, and an App Engine flexible environment
• Connectivity services to private on-premises networks using cloud VPN tunnels or cloud interconnect services
• Traffic distribution from Google Cloud load balancers and the backends running inside GCP

GCP projects can have multiple VPC networks that can contain several subnets for each region they cover, as shown in the following diagram:

Figure 1.19 – VPC network overview

VPC networks logically separate resources, even though they are in the same project. As shown in Figure 1.17, Compute Engine instances that stay in the same network can communicate with each other, even though they are in different regions without using public internet. On the contrary, instances in the same regions but different networks cannot communicate with each other unless they pass through the public internet or over VPC peering between the different VPC networks.

VPC networks have the following properties:

• Networks are global resources and do not belong to any region or zone. They are contained in one specific project and may span across all the available GCP regions.
• Networks use subnets to logically group GCP resources in one region. Therefore, subnets are regional resources, and they span across zones.
• Networks do not have any IP addresses assigned, while subnets do and they belong to private IPv4 ranges.
• Routes and firewall rules are global resources, and they are associated with one network.
• Firewall rules control the traffic to and from a virtual machine.
• Networks only support IPv4 unicast traffic. Multicast, broadcast, or IPv6 traffic within the network are not supported.

There are two ways to create a VPC network within a GCP project:

• Auto mode: The network has one subnet for each available region and default predefined firewall rules. The IP address range has a fixed /20 for each subnet that's created.
• Custom mode: The network has no default preconfigured subnets and the user has full control over defining all the network resources, such as subnet IP ranges, firewalls, and routing configuration.

In this section, you learned about the basics of VPC and its main components. In the next section, you will get an overview of Load Balancing, DNS, and CDN in GCP.

Overview of Load Balancing, DNS, and CDN

In GCP, load balancers can help distribute traffic across multiple Compute Engine instances. This reduces the risk of having performance issues on the backend application and improves reliability. Moreover, Google Cloud Load Balancing services are engineered on fully distributed and scalable infrastructure that uses software-defined networking to direct traffic to VPC networks. This helps avoid a single point of failure and allows traffic at scale.

The Google Cloud Load Balancer architecture can be represented as follows:

Figure 1.20 – Cloud Load Balancer architecture in GCP

External Google Cloud load balancers provide the following features:

• A single external IP address as the frontend
• Global or regional load balancing to reach your application from the internet
• Internal load balancing
• Layer 4 to Layer 7 load balancing

When it comes to DNS, it is important to clarify which Google Cloud products are needed and when. Google offers three services that deal with DNS:

• Internal DNS
• Cloud DNS
• Cloud Domain

Internal DNS allows Compute Engine instances in the same VPC network to communicate via internal DNS names. Internal records for the virtual machine are created in the DNS zone for .internal domains. These records are automatically created, updated, and removed by GCP, depending on the virtual machine's life cycle. Moreover, internal DNS is for the virtual machine's primary internal IP address resolution and it cannot be used to resolve its public IP address, nor its private secondary IP address. Additionally, Google recommends using zonal DNS to improve reliability. The fully qualified domain name (FQDN) for a Compute Engine instance has the following format:

instanceName.zone.c.projectId.internal

Note that to avoid conflict with FQDNs, two Compute Engine instances running in the same zone must have unique instance names.

Cloud DNS is a Google-managed service that allows us to publish domain names to the global DNS in a reliable, cost-effective, and scalable way. Cloud DNS provides both public and private zones and lets the user publish DNS records without worrying about managing its DNS server. Public zones are visible globally, while private zones are visible to one or more specified VPC networks.

Cloud Domain allows users to register and configure domains in Google Cloud. Through Cloud Domain, users can purchase domains and attach them to their applications. The domain is associated with a specific project and its price will be charged to the same Cloud Billing account of the user's project. Therefore, Cloud Domain can be used to search for available domains, buy them, and manage their registration.

Google Cloud offers a managed service to implement a content delivery network to serve content closer to users. The name of this service is Cloud CDN. Through Google's global edge network, Cloud CDN can accelerate websites and applications and improve the user experience. Cloud CDN requires an HTTP(S) load balancer that provides the frontend IP address that receives users' requests and forwards them to the backends. In GCP, there are distinct types of backends that can work with Cloud CDN:

• Managed instance groups: Groups of Compute Engine instances running on a region with autoscaling
• Zonal Network Endpoint Groups (NEGs): A group of IP addresses of running virtual machines or containers in one specific zone or a group of IP addresses and ports of running services
• Serverless NEGs: A group of serverless services such as Cloud Run, Cloud Functions, or App Engine sharing the same URL
• Internet NEGs: A group of IP addresses running outside GCP
• Cloud storage bucket: GCP object storage that's used to store any type of file at scale

All these backend types are called origin servers when we consider the Cloud CDN architecture. The following diagram shows how responses from origin servers flow through an HTTP(S) load balancer and are delivered to the final users via Cloud CDN:

Figure 1.21 – Cloud CDN HTTP(S) user responses in GCP

In this section, you learned about the basics of global load balancer services, DNS, and CDN in GCP. In the next section, you will explore DevOps, containers, and Kubernetes.