Blog

Architecting Compute Engine Solutions in GCP

Oct 20, 2022

Christopher Shaun Godwin

Author

Compute Engine Services

Each of these services have different use cases. You’ll have to know how to select the right one for your requirements.

Service	Use Case	Fancy Buzzword
Compute Engine	If you need root access and are running multiple processes in the same operating system instance.	Infrastructure as a Service (IaaS)
App Engine	You need to run a nodeJS, Java, Ruby, C#, Go, Python or PHP application quickly with no configuration or management.	Platform as a service (PaaS)
Cloud Functions	You need to run a serverless routine.	Executions as a Service (EaaS)
Cloud Run	Run individual containers.	PaaS
Kubernetes Engine	Run several docker containers in group.	Containers as a Service (CaaS)
Anthos	Run containers in a hybrid or multi-cloud environment.	Hybrid CaaS

GCE

Compute Engine is an Infrastructure as a Service solution that is the underlying platform for many services like Cloud Functions. Compute Engine provides virtual machines called instances.

New virtual machines require a type be specified along with boot image, availability status, and security options. Machine types are sorted into different CPU and Memory options. Machine types are grouped into families like general purpose, cpu optimized, memory optimized, and GPU-capable.

Compute Instance Options

General Purpose
- shared-core
- standard
- high memory
- high cpu
CPU Optimized
- Standard
Memory Optimized
- Mega-memory
- Ultra-memory
GPU Capable
- Type of GPU / GPU Platform
Disk
- Standard Persistent Disk (SPD)
- Balanced Persistent Disk (BPD)
- SSD Persistent Disk (SPD)
- Extreme Persistent Disk (EPD)
- Disk size

Compute Disk Options

Type	Workload
Standard Persistent Disks	Block storage for large processing with sequential I/O
Balanced Persistent Disks	SSDs which balance cost for less performance with a higher IOPS than SPDs
SSD Persistent Disks	Low latency, high IOPS in the single digit milliseconds, databases
Extreme Persistent Disks	sequential and random access at highest IOPS that is user configurable

Compute disks are encrypted automatically with Google managed keys or customer managed keys with Google KMS which allows storage outside of GCP. Virtual machines run in your Google project as the default GCE service account though you can specify which service account the VM runs as.

Sole-tenancy

Sole-tenant VMs in Google compute engine offer a high degree of isolation and security for your workloads. By running your VMs on dedicated hardware, you can be sure that your data and applications are protected from other users on the same system. Additionally, sole-tenant VMs can be configured with custom security settings to further protect your data.

Good for Bring Your Own License (BYOL) applications that are based on the number of CPUs, cores, or memory. Sole tenancy VMs can allow CPU overcommit so that unused cycles can be given to other instances to balance performance fluctuations.

Preemptible VMs

Preemptible VMs are a type of VM offered by Google Compute Engine at a discounted price. These VMs may be preempted by Google at any time in order to accommodate higher priority workloads. Preemptible VMs are typically used for batch processing jobs that can be interrupted without affecting the overall workflow.

Preemptible VMs can run for a maximum of 24 hours and are terminated but not deleted when preempted. You can use preemptible VMs in a Managed Instance Group. These types of virtual machines cannot live migrate and cannot be converted to a standard VM. The compute SLA doesn’t cover preemptible or spot VMs.

Shielded VMs

Shielded VMs in Google Compute Engine provide an extra layer of security by enabling features like secure boot and vTPM. These features help to ensure the integrity of the VM and its contents. Additionally, integrity monitoring can be used to detect and respond to any changes that occur within the VM. By using shielded VMs, businesses can protect their data and applications.

Secure boot is a UEFI feature that verifies the authenticity of bootloaders and other system files before they are executed. This verification is done using digital signatures and checksums, which are compared against a known good value. If the signature or checksum does not match, the file is considered malicious and is not executed. This helps to protect the system from bootkits and other forms of malware that could be used to gain access to the system.

A vTPM is a virtual Trusted Platform Module. It’s a security device that stores keys, secrets, and other sensitive data. Measured boot is a security feature that verifies the integrity of a system’s boot process. The vTPM can be used to measure the boot process and verify the integrity of the system. This helps ensure that the system is not compromised by malware or other malicious software.

Integrity monitoring is the process of verifying the accuracy and completeness of data. This is typically done by comparing a trusted baseline to current data, looking for changes or discrepancies. Logs can be used to track changes over time, and integrity checks can be used to verify the accuracy of data. Sequence integrity checks can be used to verify the order of events, and policy updates can be used to ensure that data is properly protected. In the context of a Shielded VM this is all built into the boot up process of the instances of this type.

Confidential VMs

Confidential VMs in Google Compute Engine encrypt data in use, providing an extra layer of security for sensitive information. By encrypting data at rest and in transit, confidential VMs help ensure that only authorized users can access it. Additionally, Confidential VMs can be used to comply with industry-specific regulations, such as HIPAA.

These VMs run on host systems which use AMD EPYC processors which provide Secure Encrypted Virtualization (SEV) that encrypts all memory.

Recommender

Google Compute Engine offers a recommender system that can help optimize your compute engine workloads. The recommender system uses Google’s extensive data and machine learning expertise to recommend the best way to save on cloud expense, improve security, and make your cloud usage more efficient.

Recommenders

Discount recommender
Idle custom image recommender
Idle IP address recommender
Idle persistent disk recommender
Idle VM recommender

Instance Groups

An instance group is a cluster of VMs that are managed together. Google Compute Engine offers both managed and unmanaged instance groups. Managed instance groups are well suited for instances that need to be closely monitored and controlled, such as web servers or database servers. Unmanaged instance groups are not identical and so they are not ‘managed’ by an instance template.

An instance template is a blueprint for creating virtual machines (VMs) in Google Compute Engine. You can use an instance template to create as many VMs as you want. To create a VM from an instance template, you must specify a machine type, disk image, and network settings. You can also specify other properties, such as the number of CPUs and the amount of memory.

Advantage of Managed Instance Groups (MIGS)

Minimum availability, auto-replacement on failure
Autohealing with healthchecks
Distribution of instances
Loadbalancing across the group
Autoscaling based on workload
Auto-updates, rolling and canary

Compute Engine Use Cases

GCP Compute Engine is a flexible, customizable platform that provides you with full control over a virtual machine (VM), including the operating system. This makes it a good choice for a wide range of workloads, from simple web applications to complex data processing and machine learning tasks.

GCP Compute Engine can be used to create a VM from a container image. The base image can be stored in GCS or GAR, and GCE uses COS to deploy the image. This allows for a more flexibility and full control over all aspects of a VM running docker.

Cloud Run is a GCP managed service for running stateless containers. It is a serverless platform that allows you to run your code without having to provision or manage any servers. All you need to do is supply your image and Cloud Run will take care of the rest. Cloud Run scales automatically, adjusting your container up or down based on traffic demands.

Google Cloud Platform’s Compute Engine can be used for a variety of workloads, from simple web apps to complex distributed systems. Cloud Run is a good option for running stateless web applications or microservices, while Kubernetes can be used for managing containerized workloads at scale. App Engine is also a popular choice for web applications, offering both standard and flexible environments. In addition, Compute Engine can be used for batch processing, analytics, and other compute-intensive workloads.

GCP Compute Engine root access is granted through the cloud console or SSH. Once logged in, you can install packages and run configuration management agents. This gives you full control over your server and its environment.

GCP Compute Engine is a powerful platform for running stateful applications such as databases, accounting systems, and file-based transaction engines. The platform provides high performance, scalability, and reliability specifically for these workloads, making it a good choice for mission-critical applications. In addition, GCP Compute Engine offers a number of features that make it easy to manage and deploy stateful applications, such as automatic failover and snapshotting.

GCP Compute Engine is a high security environment that offers Shielded VMs and sole-tenancy. This makes it a good platform for BYOL. Shielded VMs offer increased security by protecting against malicious activities such as rootkits and bootkits. Sole-tenancy provides an additional layer of security by ensuring that only authorized users have access to the platform.

Cloud Functions

Cloud functions are a type of serverless computing that allows you to execute code in response to events. This means that you can write code that will be triggered in response to certain events, such as a user request or a file being uploaded. This can be used to invoke additional processing, such as sending a notification or running a report. Cloud functions are a convenient way to add extra functionality to your application without having to provision and manage a server.

Event triggers are a good way to automate tasks in Google Cloud Functions. You can use event triggers to respond to events from HTTP requests, logging, storage, and Pub/Sub. Event triggers can make your life much easier by automate tasks that would otherwise be manual. For example, you can use an event trigger to automatically archive old logs when they’re created, or to automatically delete files from storage when they’re no longer needed.

Cloud Function Triggers

Broadly, triggers fall into two categories:

HTTP triggers, which react to HTTP(S) requests, and correspond to HTTP functions.
Event triggers, which react to events within your Google Cloud project, and correspond to event-driven functions.

HTTP Triggers

You can use these HTTP methods:

GET
POST
PUT
DELETE
OPTIONS

Depending on configuration, HTTP triggers to Cloud Functions can be by both authenticated and unauthenticated means.

Event Triggers

Pub/Sub triggers
Cloud Storage triggers
Generalized Eventarc triggers
- Supports any event type supported by Eventarc, including 90+ event sources via Cloud Audit Logs

Execution runtimes

dotnet core
Ruby
PHP
Node.js
Python 3
Go
Java 11

Requests are handled one at a time on a Cloud Function instance. If the instance doesn’t exist it’ll be created. You can specify the maximum number of concurrent instances for a function. HTTP triggered functions are executed at most once and other event triggers are ran at least once. Cloud Functions need to be idempotent, meaning that when ran multiple times does less and less work until the work is complete. When an idempotent script is ran after all work is completed, no work is performed.

::: tip Idempotent A script that downloads all of the pages of a website may be interrupted. If it picks up where it left off on a rerun, or especially if it doesn’t redownload the entire site on that rerun, it is idempotent. :::

Cloud Function Use Cases

Do something when something is uploaded to a Cloud Storage bucket
Run functions such as sending messages when code is updated
If a long app operation is issued, send a pub sub message to a queue and run a function around it
When a queued process completes, write a pub/sub message
When people login, write to an audit log

GKE

Google Kubernetes Engine (GKE) is GCP’s Kubernetes managed offering. This service offers more complex container orchestration than either App Engine or Cloud Run.

Kubernetes can be used for stateful deployments with certain storage objects configured into your deployment. Kubernetes has internal hooks that are auto configured by Google to provide you with GCP provisioned architecture when you deploy it. Kubernetes has different storage classes and some can be marked as default. This way when you provision an object of kind persistentvolumeclaim, a Cloud persistent disk is spun up, attache to the node running the pod, then mounted into the pod per your specifications.

To put it simple: it will create a cloud volume and mount it where you say in your yaml. You can install your own storage controllers by creating the yaml for one, creating a template that generates one(helm chart), or by following third party storage controller instructions.

The NFS-Ganesha storage controller is a robust, durable way to share highly available disks across a whole region in a cluster or set of clusters. You can set persistent volume defaults so that they don’t delete when you delete a k8s object, that way you can specify it in a create-once, reattach many deployment style. You can use logging and monitoring to initiate manual deletes when there are orphaned volumes in the process.

In k8s a combination of privoxy, istio and cert manager can secure connections between pods to institute a trust-no-one level of security. Here we assume your pods can be compromised so we configure them to only talk to the pods which we want and disallow the rest. We can disallow internet access and poke holes only to the services we need. We can ingress only to customer facing services and even put some armor on it by placing CloudFlare or Akamai in front of the services. In this model, we disallow all incoming connections to the ingress that aren’t from on-premises or from the proxies we may put in front of your customer facing services.

GKE Orchestrates the following operations:

Service discovery
Error correction and healing
Volume create, deletion, resizing
Load Balancing
Configuration
Restarts, Rollouts, and Rollbacks
Optimal resource allocation
Resource Versioning
Secrets management

As Free and Open Source Software(FOSS), Kubernetes can be self hosted, third-party hosted, or managed as it is hosted. Anthos is Google’s implementation of that designed to connect to the popular clouds and on-premises.

Kubernetes Cluster Architecture

Kubernetes is organized into nodes and masters. Masters usually only have one unless replicated or made highly available by whatever means. Nodes usually connect to masters but managed kubernetes options often group the nodes into node pools.

Default Node Pool

There is a default node pool with no toleration or taints specified, defaulted nodes will be added to this pool unless specified. In GKE node pools are specified when you provision the cluster. If using terraform your GKE module or resource ought to specify.

Kubernetes Workloads

Pods
Services
ReplicaSets
Deployments
Persistent Volumes
StatefulSets
Ingress
Node pool
CronJob

Pods are units of containers. Pods are basically containers if they only have one, but if there are many containers in a pod, consider them a dual headed container that shares networking.

Pods are ephemeral, their file systems are removed and recreated upon start up. Any stored data needs to be placed in storage via a volume and volumemount. Pods are deployed by the scheduler on nodes per no rules or specified rules.

ReplicaSets are controllers which scale pods up and down per specifications in the deployment.

Services are in-custer dns abstractions as proxies which route to to pods.

Deployments are controllers of pods running the same version of a container artifact.

PersistentVolumes are volumes requested from storage controllers, either CSI requests volumes from the cloud which attaches to a specific Kubernetes Node. Other types of volumes exist as different storage class attributes on the persistent volume.

PersistentVolumeClaims are the ways pods refer to a persistentvolume.

StatefulSets are like deployments in that they create pods, but the pods are always named the same consistent name with the replica number appended starting with zero.

Ingress objects define rules that allow requests into the cluster targeting a service. Some ingress gateways are capable of updating cloud dns entries directly while there’s always a docker image out there which will watch your public ips on your ingress load balancers and update Cloud DNS.

Node Pools are commonly labeled and generally of the same hardware class and size with the same disk geometry across nodes. One can run an NFS Ganesha storage controller from helm chart on a certain set of node pools using a shared volume on the instances. You can run one or two nodes in that pool and consider it a storage pool and then create another node pool that is your workload node pool, whose pods utilize the storage controller’s storage class. Kubernetes does the automatic job of connecting the NFS controller pods to the service pods. The controller pods can use PersistentVolumes of a more durable gcp default storage class which uses persistent disks.

Node pools and their labels allow pods to be configured with nodeAffinities and nodeSelectors among other ways of matching workloads to pools designed to handle their resource consumption.

Types of Clusters

Kubernetes Clusters come in two forms:

Standard
Autopilot

Standard is the most flexible but Autopilot is the easiest and requires the least management.

Feature	GKE Standard	GKE Autopilot
Zonal	🟢	🔴
Regional	🟢	🟢
Add Zones	🟢	⚪
Custom Networking	🟢	🔴 VPC native
Custom Version	🟢	🔴 GKE Managed
Private Clusters	🟢	🟢

Kubernetes Networking

Inside the cluster, networking is generally automatic. Outside the cluster, huge workloads, however, will often have to build node pools on top up subnets which are large enough for the NodePool to scale into.

Within the cluster service networking is handled by:

Ingresses: which stand up external load balancers that direct traffic at one of the services in the cluster.
Services
- ClusterIP, a private ip assigned to the vpc subnet that the cluster is using
- NodeIP, the ip of the node a pod is running within
- Pod IP, local private networks

Like the subnets of the nodepools, you’ll have to give pod subnets enough room to run your pods.

Service Types

Services can either be LoadBalancer for an external loadbalancer, ClusterIP for an ip that is only accessible within the cluster.

NodePort type services use an assigned port from the range 30000-32768 on the Node IP of the node that the pods which the service points to runs in.

LoadBalancers automatically create NodePort and ClusterIP resources and externally route traffic to them from a Cloud Provided LoadBalancer.

Load balancing across pods and containers is automatic, while service loadbalancing is external.

Cloud Run

Google Cloud Run is a serverless and stateless computing platform for container images. This product is well suited for deploying microservices and handling large scale data processing jobs. Cloud Run is scalable and can be deployed on demand.

You aren’t restricted to a set of runtime options, you build your runtime as a docker image and push to Google Artifact Registry or Google Container Registry. Google Cloud Run pulls the image and runs it.

::: tip Cloud Run Availability Google Cloud Run has regional availability. :::

If you app can only handle a single request or if that request uses most of the container’s resources, set its replica count to 1. You can set the maximum amount of requests a container can handle before it is killed and restarted. You can also adjust for avoiding cold starts by setting the minimum available count.

Each Cloud Run deployment is considered a revision and rollbacks when the latest revision is unhealthy is automatic. In fact, the health of a new revision is verified before traffic is sent to the most recent deployment. Each deployment in Cloud Run is a set of yaml syntax configuration that can live in a repo or inside Cloud Run itself. You can run gcloud against this file to issue new deployments or you can use command line options.

App Engine

App Engine is a serverless PaaS that runs on Google’s compute engine. It is fully managed, meaning you only need to provide your code. App Engine handles the rest, including provisioning servers, load balancing, and scaling.

Standard

App Engine Standard is a serverless environment that runs on Google’s compute engine. It is a fully managed PaaS that requires only code. There are no servers to manage. You simply upload your code and Google detects how to build it and runs it on App Engine.

Standard Code Environments

Python 2.7, Python 3.7, Python 3.8, Python 3.9, and Python 3.10.
Java 8, Java 11, and Java 17.
Node. js 10, Node. js 12, Node. js 14, Node. js 16.
PHP 5.5, PHP 7.2, PHP 7.3, PHP 7.4, and PHP 8.1.
Ruby 2.5, Ruby 2.6, Ruby 2.7, and Ruby 3.0.
Go 1.11, Go 1.12, Go 1.13, Go 1.14, Go 1.15, and Go 1.16.

App Engine Standard provides two types of instance classes or runtime generations: first-generation and second-generation. First-generation instance classes are legacy, while second-generation instance classes are offered for Python 3, Java 11 & 17, Node.js, PHP 7, Ruby, and Go >= 1.12. The F1 class is the default instance class and provides 600Mhz CPU limit and 256MB of memory. The maximum instances can have is 2048MB or ram and 4.8Ghz Compute speed.

First generation is provided for Python 2.7, PHP 5.5, and Java 8.

App Engine Flexible

App Engine Flexible allows you to customize the runtime via Dockerfile. This gives you the ability to modify the supported App Engine Flexible runtime and environment. You can also deploy your own custom containers. This makes it easy to scale your app and keep it running in a consistent environment.

Go
Java 8
dotnet
Node.s
PHP 5/7
Python 2.7 and 3.6
Ruby

Custom Runtimes

You can SSH into App Engine instances run custom docker containers and specify CPU and memory configuration. Other features include:

Health Checks
Automatically updated
Automatic replication of VM instances
Maintenance restarts
Root access

Use Cases

App Engine can be used for a variety of applications, from simple websites to complex applications that handle millions of requests. Some common use cases include:

Web applications: App Engine can host standard web applications written in languages like PHP, Java, Python, and Go.
Mobile backends: App Engine can be used to power the backend of mobile applications written in any language.
API services: App Engine can be used to build APIs that can be consumed by other applications.
IoT applications: App Engine can be used to build applications that collect and process data from IoT devices.
Data processing applications: App Engine can be used to build applications that process large amounts of data.

App Engine Flexible Key Differences from GCE

Flexible containers are restarted once a week
SSH can be enabled, but is defaulted to disabled
Built using cloud build
Settings controlled location and automatic collocation

App Engine includes a cron service, and deploys into many zones by default. App Engine is designed to run stateless workloads but you can write to disk on App Engine Flexible. App Engine provides task queues for a synchronous and background computing.

Anthos

Google Cloud Anthos is a cloud computing service that provides the flexibility to run your containerized applications on-premise or in the cloud.

At its core, Google Cloud Anthos offers access to the benefits of the cloud without having to move all of your applications there. So you’ll be able to use the same tools, processes, and infrastructure you’re used to today—and still access the benefits of having a global platform.

Google Cloud Anthos offers security and privacy by design; it’s built with multi-factor authentication and encryption at all levels of data storage, from internal compute instances to external storage systems. It also has built-in threat detection capabilities that alert you when something seems fishy.

Google Cloud Anthos gives you access to powerful analytics features through its real-time reporting dashboard and machine learning algorithms that help you make better decisions based on data. Because everything runs in a virtual environment on Google’s worldwide network of datacenters, there are no limits on how many applications can run at once, so long as they’re all within one region or continent.

Anthos:

Centrally managed
Can use Version Control Based rollbacks
Centralizes infrastructure in a single view
Centralizes deployments and rollouts
Enables Code instrumentation(performance measurements) using ASM
Uses Anthos Service Mesh(ASM) for auth and cert based routing

::: tip Anthos is just Kubernetes designed to run in GCP, other cloud providers, and on-premises. :::

Anthos Service Mesh

Service meshes are patterns which provide common frameworks for intra-service communication. They’re used for monitoring, authentication, networking. Imagine wrapping every service in an identity aware proxy, that’s a service mesh. Difficult to set up initially, service meshes save time by defining systematic policy-compliant ways of communicating across infrastructure. Facilitating hybrid and multi-cloud communications is what Anthos Service Mesh does.

ASM is built on istio which is an open source service mesh. In a service mesh there is a control plane which configures sidecar proxies running as auxiliary services attached to each pod.

Anthos Service Mesh:

Can control the traffic between pods on the application and lower layers.
Collects metrics and logs
Has preconfigured Cloud Monitoring Dashboards
Service authentication with mutual TLS certificates
Encryption of communication with the Kubernetes Control Plane

ASM can be deployed in-cluster, across Compute VMs or via Managed Anthos Service Mesh. In-cluster options include running the control plane in kubernetes to manage discovery, authentication, security and traffic. With managed ASM Google managed the control plane, maintains it, scales it and updates it. When running istiod on Compute Engine, you can have instances in groups take advantage of using the service mesh. Anthos Service mesh only works on certain configurations for in-cluster VMWare, AWS EKS, GCP GKE and bare metal, while you must use an attached cluster if using Microsoft AKS.git

Multi-cluster Ingress

The Anthos Multi-Cluster Ingress controller is hosted on Google Cloud and enables load balancing across multi-regional clusters. A single virtual ip address is provided for the ingress object regardless of where it is deployed in your hybrid or multi cloud infrastructure setup. This makes your services more highly available and enables migration from on-premises to the cloud.

The Ingress controller in this case is a globally replicated service that runs outside of your cluster.

Anthos Deployment Permutations

You can deploy anthos a number of ways depending on your needs and the features you would like to utilize. ASM and Anthos Config Management(ACM) are included in all Anthos deployments.

Traffic rules for TCP, HTTP(S), & gRPC
All HTTP(S) traffic in and out of the cluster is metered, logged and traced
Authentication and authorization at the service level
Rollout testing and canary rollouts

Anthos Config Management uses Kustomize to generate k8s yaml that configures the cluster. Yaml can be grouped into deployed services and supporting infrastructure. An NFS helm chart might be deployed to a cluster using ACM at cluster creation time to support a persistentvolume class of NFS within the deployment yaml.

ACM can be used to create initial kubernetes serviceaccounts(KSAs), namespaces, resource policy enforcers, labels, annotations, RBAC roles and role bindings. GKE Anthos deployments support a number of features:

Node auto provisioning
Vertical pod autoscaling
Shielded GKE Nodes
Workload Identity Bindings
GKE Sandboxes

ACM, ASM, Multi-Cluster ingress, and binary authorization also come with the GKE implementation of Anthos.

On-Prem Anthos GKE On-prem includes these features:

The network plugin
Anthos UI & Dash
ACM
CSI storage and hybrid storage
Authentication Plugin for Anthos
When running VMWare
Prometheus and Grafana
Layer 4 Load Balancers

Anthos on AWS includes:

ACM
Anthos UI & Dashboards
The network plugin
CSI storage and hybrid storage
Anthos Authentication Plugin
AWS Load Balancers

Attached Clusters which run on any cloud or On-prem have these features:

ACM
Anthos UI & Dash
Anthos Service Mesh

AI and Machine Learning

GCP offers several AI options and machine learning options. Vertex AI is an AI platform that offers one place to do machine learning. It handles development, deployment and scaling the ML models. Cloud TPUs are training accelerators for training deep networks.

Google also provides:

Speech-to-Text
Text-to-Speech
Virtual Agents
Dialogflow CX
Translation
Vision OCR
Document AI

Vertex AI

Vertex AI is basically a merger of two products: AutoML and the AI Platform. The merged Vertex AI provides one api and one interface for the two platforms. With Vertex you can train your models or you can let AutoML train them.

Vertex AI:

Supports AutoML training or custom training
Support for model deployment
Data labeling, which includes human assisted labeling training examples for supervised tasks
Feature store repo for sharing Machine Learning features
Workbench, a Jupyter notebook development environment

Vertex AI provides preconfigured deep learning VM images and containers.

Cloud TPU

Cloud TPU are Cloud Tensor Processing Units(TPUs) that are Google designed application specific integrated circuits(ASICs). They can train deep learning models faster than GPUs or CPUs. A Cloud TPU v2 can offer 180 teraflops, and a v3 420 teraflops. Groups of TPUs are called pods and a v2 pod can offer 11.5 petaflops while a v3 pod provides over 100 petaflops.

You can use Cloud TPUs in an integrated fashion by connecting from other Google services, for example, the Compute VM running a deep learning operating system image. TPUs come in preemptible form at a discount.

Dataflows and Pipelines

The model of the monolithic application is dead. It may be tempting to put your whole business on one web application. But when an enterprise runs an application at scale, there are dozens of supporting applications that ensure reliability, applications which meter the availability, and application code which deploys highly customized pipeline steps and standards, especially in the financial industry. At Enterprise scales, the pipeline or workflow steps have a Check to Action Ratio(CtAR) of probably 1 to 20. This means we’ll have about 20 checks, tests, tracking, metering, or logging steps to one step which actually makes a change like kubectl or cf push. And that’s just deployment.

To illustrate this dimension further there’s disaster recovery, durability, maintenance, ops and reporting all done as part of Continuous Deployment Standards. Therefore, each application is an ecosystem of standards and reporting.

Add to that that a company is often now an entire ecosystem of applications which work together, this is especially true for Internet of Things companies, for example. Some of these operations may have even been made auxiliary by leveraging some serverless functions, triggers, or webhooks.

Consider, for a moment, a vehicle insurance claim made on behalf of a driver by their spouse, the processing workflow of the claim might look like this:

Verifying that the spouse is on the policy and has access to file a claim.
Analyzing the damage and repair procedures and assigning a value to the damage
Reviewing the totals to make sure the repairs don’t exceed the value of the vehicle
Any fraud compliance reviews
Sending these interactions to a data warehouse for analysis
Sending the options and communications of circumstance to the claimant

Different applications monolithic or not will process this data in different ways.

If you buy a product online the inventory application may be a monolithic system or microservices, it may be separate or built into something else, but likely it is independent is some wise. A grocery story self checkout application would have to interact with this inventory application much like a cashier’s station. Each station is a set of services from the receipt printer to the laser scanner to the payment system. A simple grocery story transaction is not so simple and is fairly complex.

It is of key importance to consider the entire flow of data when designing for GCP.

Pub/Sub Pipelines

Cloud Pub/Sub is a giant buffer. It comes in regular and lite flavors. It supports pushing messages to subscribers or having subscribers pull messages from the queue. A message is a record or entry in the queue.

With push subscriptions, Pub/Sub makes and HTTP POST to a push endpoint. This method benefits when there is a single place to push in order to process the workload. This means it’s a good way to post to a Cloud Function, App Engine App, or Container.

Regarding pull subscriptions, services read the messages from the Pub/Sub topic. This is the most efficient method for processing large sets of messages within a topic. Pub/Sub works best when it is used as a buffer between communicating services. These services cannot have synchronous operations due to load, differences in availability, or differences in resource pools serving the sending and receiving services. Consider a service that can quickly collect and send messages. It certainly uses less resources than the consuming services which has to do additional processing work on the messages. It is likely that at some point in time the sending service will be able to exceed the speed of the consuming service. Pub/Sub can bridge that gap by buffering the messages to the processing service. In a synchronous design, messages would be lost if there was no place for the sending service to put them. In this case Pub/Sub bridges the gap.

::: tip Pub/Sub is good for buffering, transmitting or flow controlling data. If you need to transform the data, Cloud Dataflow is the way to go. :::

Cloud Dataflow Pipelines

Cloud Dataflow is Apache Beam stream processing implemented as a fully managed Google Cloud Platform service. Normally you’d have to provision instances of this service on virtual machines, but Google managed the entire infrastructure for this service and maintains its availability and reliability.

The service works via processing code written in Python, Java or SQL. Code can be batch or stream processed. You can combine services and send the output from Dataflow into Dataproc or BigQuery or BigTable and so forth. Dataflow is organized into pipelines that are designed to tackle the work of the part of the app that comes after ingests data, but otherwise can be used anywhere Apache Beam is used in applications.

Cloud Dataproc

Dataproc is managed Spark + Hadoop. This is for stream / batch processing and machine learning at the largest magnitudes. Dataproc clusters are stood up and taken down quickly so they’re often treated as ephemeral after they produce batch results. Obviously a stream processing effort may run all the time, but if the stream is some sort of live data from an occasional event, like Olympics score data or Sports, can create the need for ephemeral clusters in either case.

Dataproc is already integrated with BigQuery, BigTable, Cloud Storage, Cloud Logging, Cloud Monitoring. This services replaces on-premises clusters in a migration.

Cloud Workflows

Workflows are HTTP api services and workflows. In conjunction with Cloud Run, Cloud Functions, GitOps webhooks, Cloud Build Triggers and so forth, you can accommodate any business and technical requirements. You set them up as yaml or json steps.

You can trigger a workflow to make several api calls in sequence to do a workload. Workflows do not perform well processing data, rather they do smaller actions in a series well. You wouldn’t use workflows to make large http POST calls.

Cloud Data Fusion

Another managed service, Cloud Data Fusion is based on something called Cask Data Application Platform (CDAP), which Atlassian defines as “a developer-centric middleware for developing and running Big Data applications. Before you learn how to develop and operate applications, this chapter will explain the concepts and architecture of CDAP.”

This platform allows the ELT pattern of extraction, load, and transform as well as the ETL pattern of extraction, transformation, load. It allows this without any coding. CDAP allows drag and drop interfaces as a no-code development tool that has around 200 connectors and transformations.

Cloud Data Fusion instances are deployed as one in three versions: developer, basic, and enterprise.

Developer	Basic	Enterprise
low cost but limited	visual editor, preloaded transformations, and an SDK	streaming, integration, high availability, triggers and schedules

Cloud Composer

Composer is basically a managed instance of Airflow which is a workflow coordination system that fires off workflows of a specific type: directed acyclic graphs (DAGs), which are python definitions of nodes and their connections. Here is an example:

import networkx as nx
graph = nx.DiGraph()
graph.add_edges_from([("root", "a"), ("a", "b"), ("a", "e"), ("b", "c"), ("b", "d"), ("d", "e")])

DAG example

example from Munging Data

These DAGs are stored in Cloud Storage and loaded in to Composer. Google gives this example on the Cloud Composer Concepts Page:

overview dag and tasks

Figure 1. Relationship between DAGs and tasks

Airflow includes plugins, hooks. operators, and tasks. Plugins are combinations of hooks and operators. Hooks are third party interfaces and operators define how tasks are run and can combine actions, transfers, and sensor operations. Tasks are work done symbolized as one of these nodes in the DAG.

Upon execution of a DAG, logs are stored in a Cloud Storage bucket. Each task has its own log and streaming logs are available.

Compute Systems and Provisioning

You can provision compute services via the console or via terraform. You can run terraform in Cloud Build or in Deployment Manager. Using Terraform allows you to perform GitOps on the processes surrounding version control, integration, pull requests and merging code. Branching strategies allow segmentation of environments. Multiple repositories can be combined into project creation code, infrastructure creation code, access granting code and its best to run all this as a privileged but guarded service account. Enterprises will use a series of layers of access, projects, folders and organizations in complex networks of infrastructure as code. It can all be pulled together using terraform modules, cloud build triggers and repository and project layering.

Compute Design problems

The key concerns when designing services that rely on compute systems are configuration, deployment, communication between services, data flows and monitoring and logging.

State

Inside the application you’ll have to work out how state will be stored either in a shared volume or in a distributed manor among your instances. This kind of design decision can leverage Cloud Storage or Persistent Volumes. Another problem is how to distribute state among instances. There are several means of doing this mathematically using modulo division on some unique attribute. You could also use aggregate level IDs.

You get around this by using things like Redis for session data and shared storage options. You make your app itself stateless in its core but know how to connect to where state information is stored. Running two replicas of Nextcloud containers requires state data be shared somehow or when you login to one, your round robin connection to the other will present you with another login screen. The browser will not be able to maintain the session data of two sessions when there’s one and therefore the disparity between the replicas will prevent the application from functioning.

So in memory caches bridge the gap between different instances. Wordpress for instance, is completely stateless(when you use Storage Bucket Media Backends) as it keeps all session and any other state data in the database so a memory cache is not needed.

Async vs Synchronous

Synchronous strategies are used when data can’t be lost. NFS mounts can be mounted async or sync, for instance. Synchronous setups require lightening fast networks that are fast than the disks involved with low to no latency and probably nothing else on the network. Otherwise if that’s not the case your system will try to save a file and will wait for the network to respond before it lets the process move on to other tasks. When a VM or bare-metal system has processes which have to wait on a slow network, the processes stack on top of each other increasing load. Load exponentially reduces a systems ability to respond to requests. Synchronous NFS systems on slow networks crash and so people can’t and therefore don’t use them.

These problems are universal across all independent systems that need to communicate over means that involve variable speeds. With Google’s premium network, however, the problem will always be rather load than network speed. Scaling ingestion, for instance, will resolve synchronous problems.

However, services like Pub/Sub can make this process asynchronous, relaxing some of the stress and impact on on such a system’s costs and reliability.

Credit card transactions are synchronous as well as maybe a bitcoin mining operation.

Overview

The most popular options provided by Google Compute Engine that cover a wide variety of use-cases include:

Dataprocessing and Workflow options include:

Exam Essentials

Know when to use particular compute services
Know all the optional features of these services
Know the differences between App Engine Standard and Flexible
Know when to use Machine Learning and Data workflows and pipelines
Understand the features of different Anthos clusters: EKS, AKS, GKE, Attached
Know Kubernetes features

Official Resources

Designing Solutions for Technical Requirements

Sep 18, 2022

Christopher Shaun Godwin

Author

High Availability

High availability is a key characteristic of any reliable system, and is typically measured by what is known as the “99999” rule. This rule states that a system must be operational 99.9999% of the time in order to be considered highly available. This equates to a maximum downtime of just over 5 minutes per year. In order to achieve such a high level of availability, a system must be designed and implemented with care, and must be constantly monitored and maintained. Additionally, a high availability system must have a robust service-level agreement (SLA) in place in order to ensure that the system meets the required availability levels.

::: tip The best general strategy for increasing availability is redundancy. :::

Table of Availability SLAs and Downtime

% Uptime	Downtime / Day	Downtime / Week	Downtime / Month
99	14 m 24 s	1h 40m 48s	7h 18m 17s
99.9	1m 26s	10m 4s	43m 49s
99.99	8s	1m	4m 22s
99.999	864 ms	6s 500ms	26s
99.9999	86 ms	604 ms	2s 630ms

When it comes to SLAs and account for hardware failures, it is important to consider network equipment and disk drives. Hardware failures can often be caused by a variety of factors, including physical damage, overheating, and software issues. By having a plan in place for how to deal with these failures, you can help minimize the impact on your business.

One way to prepare for hardware failures is to have a redundancy and a backup plan for your equipment. This way, if one piece of equipment fails, you can quickly switch to another while still running. The work of a cloud business with a 5 9s SLA is to statistically predict disk drive failures overall and plan redundancy and recover procedures. This way, if a drive fails, you actually never know there’s a problem.

::: danger Failure Stack

Application Bugs
Service problem
DB Disk Full
NIC Fails
Network fails
Misconfiguration of infrastructure or networks :::

One way to mitigate the errors that can occur during deployment and configuration is to test thoroughly before making any changes. This can be done by creating staging or lower environments that are identical to the production environment and testing all changes in it before deploying them to production. Canary deployments are another way to mitigate errors. With canary deployments, changes are first deployed to a small subset of users before being rolled out to the entire user base. This allows for any errors to be detected and fixed before they impact the entire user base. Regression testing can also be used to mitigate errors. This is where changes are tested not only in the staging environment, but also in the production environment.

Continuous deployment and continuous verification are two key concepts in minimizing downtime for deployments. By continuously deploying code changes and verifying them before they go live, we can ensure that only working code is deployed and that any issues are caught early. This minimizes the amount of time that our systems are down and keeps our users happy.

Compute Availability

Google Compute Engine is the underlying provider of the following services:

GCE VMs
GKE Masters and Worker Nodes
App Engine Applications
Cloud Functions

The process of meeting your availability needs using each of these services is slightly different for each one.

High Availability in Compute Engine

Hardware Redundancy and Live Migration

On the lowest level, much of the servers at Google have levels of redundancy. If a server fails for hardware issues, others are there for failing over to while others are booted up to replace redundancy.

Google also live migrates VMs to other hypervisors like it does when power or networks systems fail or during maintenance activities which have a real impact on hypervisors.

::: warning Live Migration

Live migration isn’t supported for the following VMs:

Confidential VMs
GPU Attached VMs
Cloud TPUs
Preemptible VMs
Spot VMs

:::

Managed Instance Groups

Managed Instance Groups(MIGs) create groups or clusters of virtual machines which exist together as instances of the same VM template.

Instance Templates A VM template looks like this:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates

Here is what you’re posting before you make replacements:

{
  "name": "INSTANCE_TEMPLATE_NAME"
  "properties": {
    "machineType": "zones/ZONE/machineTypes/MACHINE_TYPE",
    "networkInterfaces": [
      {
        "network": "global/networks/default",
        "accessConfigs":
        [
          {
            "name": "external-IP",
            "type": "ONE_TO_ONE_NAT"
          }
        ]
      }
    ],
    "disks":
    [
      {
        "type": "PERSISTENT",
        "boot": true,
        "mode": "READ_WRITE",
        "initializeParams":
        {
          "sourceImage": "projects/IMAGE_PROJECT/global/images/IMAGE"
        }
      }
    ]
  }
}

Or with gcloud

gcloud compute instance-templates create example-template-custom \
    --machine-type=e2-standard-4 \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --boot-disk-size=250GB

And then instantiate the instance template into a group.

gcloud compute instance-groups managed create INSTANCE_GROUP_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE \
    --zone ZONE

What makes it work well is that when a VM fails in the group, it is deleted and a new one created. This ensures the availability of the group.

Managed Instance Groups(MIGs) can be zonal, regional and can be autoscaled. Their traffic is load balanced and if one of the instances are unavailable the traffic will be routed to the other instances.

Multiple Regions and Global Load Balancing

Instance group’s top level is regional. You can however run many multizonal MIGs in different regions and balance them with a regional load balancer. Workload is distributed across all MIGs to each of the regional LBs. If one or more of the MIGs becomes unavailable, the global LB will exclude them from routing.

Users will be connected by the global load balancer(LB) to their closest region reducing latency.

High Availability in Kubernetes Engine

Kubernetes by default and if uses correctly provides high availability for containers and orchestrates their replication, scaling up, scaling down, container networking, service ingress. This enables canary, blue green and rollout deployments for further reliability testing.

GKE has an extra layer of availability on top of that which is provided by Kubernetes(k8s). Node pools are Managed Instance Groups of VMs running Kubernetes nodes.

Kubernetes monitors pods for readiness and liveness. Pods in k8s are replica sets of containers. Usually a pod has one container defined but often might have a sidecar or binary container pattern. Different containers in the same pod can communicate with IPC, network over localhost, or by volume. You cannot share the individual sockets but you can share the whole socket directory if you have permissions on the environment.

::: info For example PHP-FPS might need to run with the webserver it is coupled with. The nginx webserver would be configure similar to this:

        upstream webapp {
            server 127.0.0.1:9000;
        }

The would both share 127.0.0.1. :::

If one of the containers in a pod crashes, the restartPolicy directive tells k8s what to do.

Because Managed Instance groups are zonal or multizonal(regional), Kubernetes clusters are also zonal and multizonal(regional). Regional clusters have their control planes replicated across zones so if a control plane goes down, it hasn’t lost availability.

High Availability in App Engine and Cloud Functions

These services experience automatic high availability. When running these services, the items in the failure stack to worry about involve deployment, integration concerns, application failures.

High Availability Computing Requirements in Case Studies

Recall our case studies

EHR Healthcare needs a highly available API service to meet the business requirement of “entities will need and currently have different access to read and change records and information”. This is essential as it is an external-facing service for customers, vendors, and partners.
HRL requires high availability for its real-time telemetry and video feed during races to enhance the spectator experience. This is crucial to ensure uninterrupted live streaming of races.
A high availability analytics solution is needed to gain insights into viewer behavior and preferences. This will ensure uninterrupted access to critical viewer data for business decision-making.
The archival storage for past races also needs to be highly available for on-demand viewing by fans and analysts.
High availability is vital for the online video games developed by Mountkirk Games. This is necessary to ensure a seamless gaming experience for players across the globe.
The high scores and player achievements system also require high availability to record and display player scores and achievements in real time.
The user data collection system for personalizing the gaming experience needs to be highly available to collect and process user data efficiently.
For TerramEarth, high availability is essential for their IoT sensor data system, which provides crucial data for improving their products and services.
The migration of their existing on-premises data infrastructure to the cloud needs to ensure high availability to prevent any disruption to their operations.
The data analytics solution for deriving insights from sensor data also requires high availability to ensure continuous access to valuable business insights.

Storage Availability

Storage is considered Highly available when it is available and functional at all times.

GCP Storage Types

Object storage
block storage
Network attached storage
Database services
Caching

Availability refers to the quality belonging storage that its contents are retrievable right now. Durability, on the other hand, refers to the long term ability of the data to be in tact and to stay retrievable.

Availability of Different Storage Types

Object Storage

Cloud Storage is entirely managed service for storing objects, files, images, videos, backups, documents, and other unstructured data. It is always highly available as a managed service.

File storage

Cloud Filestore is a NAS that is fully managed and thus Google ensures it is highly available.

Block Storage

Persistent disks are disks that are attached to VMs but remain available after those VMs are shutoff. They can be used like any local hard drive on a server so they can store files and database backends. PDs are also highly available because they can be resized while in use. Google offers different types of persistent disks:

	Standard	Balanced	SSD	Extreme
Zonal	reliable block storage	reliable blk storage with higher IOPS	better IOPS than Balanced	Highest IOPS
Regional	PDs replicated across 2 zones within a region	dual zone replicated higher IOPS	dual zone replicated better IOPS	N/A

Better performance leads to higher costs as does going from a zonal PD to a regional PD.

Zonal Persistent Disks with a standard IOPS have a 4 9s durability(99.99%), while all the others have a 5 9s uptime(99.999%).

Availability of Databases

Self-Managed Databases

If you run your own database on a virtual machine topology, ensuring these systems are redundant is the key to managing your own database availability. The underlying db software will affect how you plan for availability in a architectural design.

For example, MySQL or MariaDB usually use master and replicas. You may want to set up a few regional sql proxy hosts and a global LB to them all to provide an endpoint for the app to all of these. Making your db cluster multiregional and therefore multizonal would involve considering the cost of network traffic, latency, consistency.

In each different sql server case you’ll have to decide if it is best to try to share a disk between active and inactive servers, filesystem replication to a standby system, or to use multimaster replication. You could also use vitesse to create your own globally available MySQL server either with containers or with virtual servers.

Or you could use Cloud SQL selecting a highly available cluster during creation and not worry about it. You could use Cloud Spanner for guaranteed consistency.

Managed Databases

HA by Default:

Firestore
BigQuery
Cloud Spanner

Have HA Options:

Cloud SQL
Bigtable

With services that have High Availability through setup or configuration, it is important to remember that seeking greater availability, say going from 3 9s to a 4 9s SLO, will cost more.

Availability of Caching

Caching is storing the most important immediate use data in low latency services to improve retrieval and storage speed. For example, using a high performance SSD on a raid array as the cache, or a redis server. Google’s managed caching service is made highly available.

::: tip Memcached and redis are supported by Google’s Cloud Memory Store. :::

High Availability Storage Requirements in Case Studies

EHR HealthCare’s active data available through the API will need to be highly durable and highly available at all times. Thier databases should take advantage of a managed database sorage solutions.
HRL needs highly durable storage for retaining permenant videos of races using archive class object storage. They also need always available storage for serving the most recent videos to audiences on their website. If transcoding is intense you might consider an extreme IOPS or SSD but a Regional SSD will have better availability. You might transcode locally and copy to an available drive.
Mountkirk will need durable and highly available Big Table as well as Firestore or Firebase Realtime Database. They can achieve this as these services are fully managed. If they required some durable volume space to share among gaming servers, highly durable Regional Balanced PDDS with backups. Their billing will be supported by Cloud Spanner.
TerramEarth will have highly available storage in BigQuery.

Network Availability

Using premium tier networing and redunant networks, you can increase network availability. If one interconnect is down, often a second will provide protection against connectivity loss. Interconnects have a minimum of 10Gbps and traffic does not cross the public internet. When crossing the internet is not a problem, Google offers and HA VPN which has redundant connections and offers a 4 9s(99.99%) uptime SLA.

Communication within Google usually uses their low latency Premium Network teir which doesn’t cross the internet and is global. Standard networking tiers will not be able to use this global network and so cannot take advantage of global load balancing. Communications within the cloud on the Standard Networking tier do cross the internet.

High Availability Network Requirements in Case Studies

Since networking requirements are not often specified, the Architect should analyze the requirements, ask questions and suggest the most cost effective solution which meets the needs of the requirements both business and technical.

Application Availability

Application Availablility is 3 parts infrastructure availability(network, storage, and compute), but its 1 part reliability engineering in the application design, integration and deployment. Logging and Monitoring is the most appropriate way to handle availability unknowns in the application. Technical and Development processes iterate over the logs and alerts in order to achieve their reliability SLOs within the application.

::: tip Add Cloud Monitoring with alerts as part of your availability standards to increase application and infrastructure reliability. :::

Scalability

This is the ability to add or remove resources based on load and demand. Different parts of the cloud scale differently and efficienly.

Managed Instance Groups, for instance, increase and decrease the amount of instances in the group.
Cloud Run when no one is requesting a resource, scales replicas of containers down to 0.
Unstructured Databases scale horizontally making consistency the main concern.

Stateless apllications can scale horizontally without additional configuration or without each unit needing to be aware of the other. Stateful applications, however, generally scale vertically but can scale horizontally with certain solutions:

Putting session data into a Redis cache in Cloud Memorystore
Shared volumes
Shared Database such as Cloud SQL

Resources of different flavors scale at different rates based on needs. Storage might need to scale up once a year while compute engine resources might scale up and down every day. Subnets do not auto scale so when creating a GKE cluster you’ll have to configure its network to handle the scaling of the node pool.

::: tip Scale database servers by allocating higher cpu and memory limits. This way, non-managed relational database servers often can handle pead load without scaling. :::

If you decouple your services which need to scale, they can scale separatley. For example, if your mail server system is a series of services on a VM like postfix, dovcot and mysql, to scale it you’d have to scale the whole VM. Alternatively, decoupling the database from your VM allows you to have more hosts that use the same information with a shared volume. Containerizing each process in the mail server, however, will allow you to scale each customer facing service to the exact appropriate level at all times.

::: warning Scaling often depends on active user count, request duration, and total memory/latency per process/thread. :::

The only network scaling you might do with GCP is increasing your on-premises bandwidth to GCP by increasing the number of interconnects or try an additional VPN over an additional internet connection.

Scaling Compute Resources

Google Compute Engine, Google Kubernetes Engine supports autoscaling while App Engine and Cloud Functions autoscale out of the box.

Scaling Compute in GCE

MIGs will scale the number of instances running your application. Statefully configured VMs cannot autoscale. Unmanaged instance groups also cannot autoscale. Compute instances can scale by CPU utilization, HTTP Load Balancing utilization, and metrics monitored with monitoring and logging.

Autoscaling policies define targets for average CPU use, this is compared to the data collected in the present and if the target is met, the autoscaling policy will grow or shring the group.

Autoscalers can make decisions and recommend a number of instances based on the metrics it is selected to use. You can autoscale based on time schedules and specify the capacity in the schedule. The Scaling schedule will operate at a start time, for a duration, with configuration about requency to reoccur. This enables to you skip slow days in the schedule. Use this option for predictable workloads which may have a long startup time. When using autoscaling with processes that have a long start, often the request times out before the scaling is completed. It is important that you use the appropriate scaling strategy to match what you’re dealing with.

When MIGs are scaled in or down, they can be set to run a script upon shutdown with a best-effort with no gaurentees. If this script is doing quick artifact collection, it will probably run. If it is doing a heavy shutdown workload, it may stall or be killed.

::: danger Cannot Autoscale

Stateful instance workloads
Unmanaged instance groups :::

Scaling Compute in GKE

Containers with sidecars or containers that run in the same pod will be scaled up and down together. Deployments specify replicasets which are sets of identically configured pods with a integer for a replica count. You can scale a deployment up from 1 to any number your worker nodes support.

Kubernetes autoscaling is split horizon, scaling the cluster and scaling what is in the cluster. Node pools are groups of nodes which have the same configuration. If a pod is deployed into a node pool that has no more resources, it will add another node to the pool.

Specifying the minimum and maximum number of replicas per depoyment with resource targets like CPU use and a threashold, in cluster scaling operates effortlessly.

Scaling Storage Resources

GCP uses virtualized storage, so a volume may not be a physical disk.

Locally attached SSD on VMs which aren’t persistent are the least scalable storage option in GCP. Preemptible VMs volumes are cleaned when VMs are preempted.

Zonal and regional persistent idsks and persistent SSDs are scalable up to 64TB while increasing performance is a matter of provisioning and migrating to a new disk with a higher IO operations per second(IOPS). Once you add a disk to a system, you have to use that systems commands to mount it and make it available for use. You may also have to sync data to it and remount it in the place of a lower performing disk. This isn’t scaling and it isn’t automatic but is often required planning to grow a design beyond its limits.

All managed services either automatically scale or must be configured to do so. BigQuery, Cloud Storage, Cloud Spanner, to name a few, provide scalable storage without effort. Big Query charges by data scanned. So if you logically partition the data by time, you can avoid scaling costs up when you scale your workload. Scanning only the last weeks of data will enable BigQuery to improve query time.

Network Design for Scalability

When designing connections from GCP with VPNs or interconnects, you need to plan for peak, or peak-plus-twenty(peak + 20%). Check with your provider as you may only be charged for traffic or bandwidth actually used.

Reliability

Reliability is repeatable consistency. Try/Catch statements are an example of reliabiity in code. If your app does the same thing all the time, but only under the circumstance it was developed in but not all the circumstances it was designed for it sn’t reliable. Another example of reliability is when an applications uses methods of quietly reconnecting to a database in the case of bandwidth issues.

Reliability is a specific part of availability which hovers around human error. Reliability Engineering is the practice of engineering to have your workload run consistently under all the circumstances which it will face within the scope of its support and design, or within the scope of what’s normal and reasonable.

To measure reliability, one measures the probability of failure and then tries to minimize it to see if they can have an affect on that measurement. This involves defining standards, best practices, identifying risk, gracefully deploying changes.

It is important to be throughly versed in your workload’s dependencies, their dependencies and the teams or organizations which provide those and the documentation produced by those entities. Knowing these trees will make the difference in the successful reliabiliy of a design.

Measuring Reliability

Uptime is one way to measure reliability, percentage of failed deployments to production to successful deployments is another. All of that shit should be wored out in lower environments. Other metrics may need to be logged or cataloged and placed in a report or dashboard for regular collection. Number of failed requests that didn’ return 200 versus number of successful requests. Each workload will have different reliability measurements. A set of microservices that together create a mail server will want to measure delierability and mail loss from the queue. You’ll have to design around these metrics.

Reliability Engineering

The design supports reliability in the long run by:

Identifying the best way to monitor services
Deciding on the best way to alert team and systems of failure.
Consider incedence response procedues those teams or systems will trigger
Implement tracking for outages, process introspection, to understand disruptions

Emphasize issues pertaining to management and operations, decide whose responsibilities are whose.

Exam Essentials

Be able to contrast availablility scalability, reliability, and availablility
Know how redundancy improves availability
Rely on managed services to increase availability and scalability
Understand the availability of GCE Migs and GKE globally loadbalanced Regionally replicate clusters
Be able to link reliability to risk mitigation

Official Resources

Designing and Planning GCP Solutions for Business Requirements

Sep 14, 2022

Christopher Shaun Godwin

Author

Key Considerations

Business Use Case & Product Strategy
Cost Optimization
Dovetail with Application Design
Integration with External Systems
Movement of Data
Security
Measuring Success
Compliance and Observability

Business Use Cases and Product Strategy

Business requirements dictate technical requirements implicitly. From statements like:

EHR HealthCare

Business Requirements

EHR Healthcare provides B2B services to various entities, including vendors, insurance providers, and network directories.
Different entities will need to have varying levels of access to read and modify records and information. This implies the need for a robust access control system.
Given the nature of their work, EHR Healthcare needs to ensure that their services are always available. High availability is thus a core business requirement.
Some of the information that entities will access is regulated, so compliance with relevant data protection and privacy laws is a must.
Confidentiality is crucial since EHR Healthcare deals with sensitive health data.
The company wants to track the number and type of data accessed and gain insights into trends. This suggests a need for a comprehensive analytics solution.
Different entities involved possess varying levels of expertise, which might require the development of user-friendly interfaces or provision of training for the effective use of EHR Healthcare’s systems.

::: tip Minimal Effort Predictions Cloud AutoML is a cloud-based tool that allows developers to train machine learning models with minimal effort. It is designed to make the process of training machine learning models easier and faster. Cloud AutoML is based on the Google Cloud Platform and offers a variety of features that make it a powerful tool for machine learning. :::

Technical Requirements

A publicly exposed API or set of APIs needs to be developed to facilitate interactions between various entities.
Access restrictions must be applied at the API level to adhere to the varying access rights of different entities.
There will be involvement of legacy systems due to insurance entities. This implies the need for systems integration or migration strategies.
Redundant infrastructure is required to ensure high availability and continuous operation of the services.
Data lifecycle management must be implemented, considering regulation, insights, and access controls.
Given the nature of their work, EHR Healthcare needs to employ Cloud Machine Learning to build insight models faster than they can be planned and built. This indicates a requirement for machine learning capabilities in their infrastructure.

Mountkirk Games

Business Requirements

Mountkirk Games develops and operates online video games. They need a robust and scalable solution to handle high scores and player achievements.
They aim to collect minimal user data for personalizing the gaming experience, complying with data privacy regulations.
The solution must be globally available to cater to their worldwide player base.
They seek low latency to ensure a smooth and responsive gaming experience.
Mountkirk Games expresses interest in Managed services which can automatically scale to meet demand.

Technical Requirements

A globally available high score and achievement system is needed to keep track of player progress and milestones.
User data needs to be collected and processed in a manner that is privacy-compliant and secure.
The system must provide low latency to ensure a seamless gaming experience, which may require a global distribution of resources.
Managed services can be used to handle automatic scaling, reducing the overhead of manual resource management.

::: tip Business to Technical Requirements When designing a new project, while collecting and studying business requirements, you’ll have to translate those into technical requirements. You’ll find that there’s not a one to one relationship. One technical solution may meet two business requirements. While one business requirement might encapsulate several solutions. :::

TerramEarth

Business Requirements

TerramEarth manufactures heavy equipment for the construction and mining industries. They want to leverage their extensive collection of IoT sensor data to improve their products and provide better service to their customers.
They aim to move their existing on-premises data infrastructure to the cloud, indicating a need for a comprehensive and secure cloud migration strategy.

Technical Requirements

IoT data needs to be ingested and processed in real-time. This involves creating a robust pipeline for data ingestion from various IoT devices, and real-time data processing capabilities.
A robust data analytics solution is needed to derive insights from the sensor data. This requires the deployment of big data analytics tools that can process and analyze large volumes of sensor data.
A migration plan is needed to move existing data and systems to the cloud.
This involves choosing the right cloud services for storage, computation, and analytics, and planning the migration process to minimize downtime and data loss.

::: tip Extract, Transform, Load It is what it says. It takes large volumes of data from different sources. Transforms it to useable data, and makes available the results somewhere for retrieval by others.

Cloud Datafusion handles these tasks for data scientists and makes it easy to transfer data between various data sources. It offers a simple drag-and-drop interface that makes it easy to connect to different data sources, transform and clean data, and load it into a centralized data warehouse. Cloud Datafusion is a cost-effective solution for businesses that need to quickly and easily integrate data from multiple sources. :::

Helicopter Racing League

Business Requirements

The Helicopter Racing League (HRL) organizes and manages helicopter races worldwide. They aim to enhance the spectator experience by providing real-time telemetry and video feed for each race.
HRL wants to archive all races for future viewing on demand. This will allow fans and analysts to revisit past races at their convenience.
A robust data analytics solution is required to gain insights into viewer behavior and preferences. This will help HRL understand their audience better and make data-informed decisions to improve the viewer experience.
The solution must be highly available and scalable to handle spikes during race events. This is essential to ensure a seamless live streaming experience for viewers, regardless of the number of concurrent viewers.

Technical Requirements

Real-time data processing capability is needed to handle race telemetry data. This involves setting up a system that can ingest and process high volumes of data in real time.
A scalable video streaming solution is needed to broadcast races worldwide. This system must be capable of handling high video quality and large volumes of concurrent viewers without degradation of service.
Archival storage is needed for storing race videos for on-demand viewing. This involves choosing a storage solution that is cost-effective, secure, and capable of storing large volumes of video data.
An analytics solution is needed for analyzing viewer behavior and preferences. This requires the deployment of data analytics tools that can process and analyze viewer data to provide actionable insights.

Application Design

Business requirements will affect application design when applications are brought into the cloud. In every set of requirements, stated or unstated will be the desire to reduce cost.

Licensing Costs
Cloud computing costs
Storage
Network Ingress and Egress Costs
Operational Personnel Costs
3rd Party Services Costs
Sanctions on missed SLA costs
Inter-connectivity charges

These contribute to the Total Cost Ownership(TCO) of a cloud project.

Managed Services

Google has a set of managed services like Cloud SQL which remove the low level work from running these services yourself.

Some of these include:

Compute Engine
- Virtual machines running in Google’s data center.
Cloud Storage
- Object storage that’s secure, durable, and scalable.
Cloud SDK
- Command-line tools and libraries for Google Cloud.
Cloud SQL
- Relational database services for MySQL, PostgreSQL, and SQL Server.
Google Kubernetes Engine
- Managed environment for running containerized apps.
BigQuery
- Data warehouse for business agility and insights.
Cloud CDN
- Content delivery network for delivering web and video.
Dataflow
- Streaming analytics for stream and batch processing.
Operations
- Monitoring, logging, and application performance suite.
Cloud Run
- Fully managed environment for running containerized apps.
Anthos
- Platform for modernizing existing apps and building new ones.
Cloud Functions
- Event-driven compute platform for cloud services and apps.
And dozens more.

To see an exhaustive list, please see My List of All GCP Managed Services

::: tip Reducing Latency on Image Heavy Applications Google Cloud CDN is a content delivery network that uses Google’s global network of edge locations to deliver content to users with low latency. It is a cost-effective way to improve the performance of your website or web application by caching static and dynamic content at the edge of Google’s network. Cloud CDN can also be used to deliver content from your own servers, or from a content provider such as a CDN or a cloud storage service.

Using Google’s Cloud CDN in combination with multi-regional storage will reduce load time. :::

Reduced-level Services

Many times when computing needs are considered, certain services with availability requirements lower than others can benefit from reduced-level services. If a job that must be processed can have those processes paused during peak times but can otherwise run normally, it can be preempted.

Reduced level services:

Preemptible Virtual Machines
Spot VMs
Standard Networking
Pub/Sub Lite
Durable Reduced Availability Storage

Preemptive VMs

Preemptible VMs are shutdown after 24 hours and Google can pause them at any time. Running process on those vms do not stop but they slow to a crawl and speed back up when services become available. You can write a robust application by setting it up to detect the preemptions. These VMs cost 60-90% or so less than their standard counterparts.

Preemptible VMs also get discounts on volumes and GPUs. Managed resource groups will replace a preempted VM when it is suspended after 24 hours. Preemptible VMs can use other services to reduce the overall cost of using those services with VMs.

::: warning Live Migration Preemptible and Spot VMs are not eligible for live migration. :::

Spot VMs

Spot VMs are the next generation Preemptible virtual machine. Though spot VMs are not automatically restarted, they can run for longer than 23 hours. Spot VMs can be set to a stopped state or be deleted on preemption. With a managed resource group of spot VMs, one can set the VMs to be deleted and replaced when resources are available.

Standard & Premium Networking

Premium Networking is the default, but Standard Tier Networking is a lower performing option. With Standard Tier Networking, Cloud Load Balancing is only regional load balancing and not global balancing. Standard Networking is not compliant with the global SLA

Pub/Sub Lite vs Pub/Sub

Pub/Sub is highly scalable but Pub/Sub Lite can be scaled providing lower levels of cost-effective service.

Pub/Sub come with features such as parallelism, automatic scaling, global routing, regional and global endpoints.

Pub/Sub Lite is less durable and less available than Pub/Sub. Messages can only be replicated to a single zone, while Pub/Sub has multizonal replication within a region. Pub/Sub Lite users also have to manage resource capacity themselves.

But if it meets your needs, Pub/Sub Lite is 80% cheaper.

App Engine Standard vs Flexible

App Engine Standard allows scaling down to zero, though the trade offs are that you can only use a set of languages, can only write to /tmp with java, can’t write with python. Standard apps cannot access GCP services, cannot modify the runtime, or have background processes, though they can have background threads.

Durable Reduced Availability Storage(DRA)

These are buckets which have an SLA of 99% availability instead of equal to and greater than 99.99% availability. Storage operations are divided into class A and class B operations:

API	Class A($0.10*/10,000 ops)	Class B($0.01*/10,000 ops)
JSON	storage.*.insert1	storage.*.get
JSON	storage.*.patch	storage.*.getIamPolicy
JSON	storage.*.update	storage.*.testIamPermissions
JSON	storage.*.setIamPolicy	storage.*AccessControls.list
JSON	storage.buckets.list	storage.notifications.list
JSON	storage.buckets.lockRetentionPolicy	Each object change notification
JSON	storage.notifications.delete
JSON	storage.objects.compose
JSON	storage.objects.copy
JSON	storage.objects.list
JSON	storage.objects.rewrite
JSON	storage.objects.watchAll
JSON	storage.projects.hmacKeys.create
JSON	storage.projects.hmacKeys.list
JSON	storage.*AccessControls.delete
XML	GET Service	GET Bucket (when retrieving bucket configuration or when listing ongoing multipart uploads)
XML	GET Bucket (when listing objects in a bucket)	GET Object
XML	POST	HEAD

* DRA Pricing

Data Lifecycle Management

Sort your data along a spectrum of most frequent to infrequent use. Spread your data along the following:

Memory Caching
Live Database
Time-series Database
Object Storage
- Standard
- Nearline
- Coldline
- Archive
Onprem, Offline storage

Objects have a storage class of either standard, nearline, coldline, or archive. Storage classes can be changed on single objects along this direction. You cannot move a storage class to a more frequent use class, only the opposite. You can move frequency lower on an object.

standard -> nearline -> coldline -> archive

storage class	`standard`	`nearline`	`coldline`	`archive`
accessing at least once per	week	month	quarter	year

::: tip Time series data Time series data is a type of data that is collected over time. This data can be used to track trends and patterns over time. Time series data can be collected manually or automatically. Automatic time series data collection is often done using sensors or other devices that collect data at regular intervals. This data can be used to track the performance of a system over time, or to predict future trends. These are examples of time-series data:

MRTG graph data
SNMP polled data
Everything a fitbit records
An EKG output

Time series data is best stored in BigTable which handles this workload better than BigQuery or CloudSQL. :::

Systems Integ and Data Management

Once we have these requirements, our minds already start placing the need in the right product, though we may be provisionally thinking about it. The same thing should be happening when you think of dependencies.

Systems Integration Business Requirements

Let’s review the business needs of our use cases.

Business requirements dictate technical requirements implicitly. From statements like:

EHR Healthcare

Business Requirements

EHR Healthcare provides B2B services to various entities, vendors, insurance providers, network directories, etc.
Different entities have different access rights to read and edit records and information.
Different entities possess varying levels of expertise.
The services must always be up and running.
Some information accessed by entities is regulated.
Confidentiality is of utmost importance.
The company wishes to track the number and type of data accessed to gain insights into trends.

Technical Requirements

They will need to publicly expose an API or set of them.
Access restrictions must be applied at the API level.
There will be legacy systems involved because of insurance entities.
Infrastructure redundancy is necessary.
Data Lifecycles must consider regulation, insights, and access controls.
Cloud Machine Learning can be leveraged to build insight models faster than they can be planned and built. ::: tip Cloud Dataflow Cloud dataflow is a cloud-based data processing service for batch and streaming data. It is a fully managed service that is designed to handle large data sets with high throughput and low latency. Cloud dataflow is a serverless platform that can scale automatically to meet the needs of your application. It is a cost-effective solution that allows you to pay only for the resources you use. :::

Helicopter Racing League

Business Requirements

The Helicopter Racing League (HRL) organizes and manages helicopter races worldwide.
HRL wants to enhance the spectator experience by providing real-time telemetry and video feed for each race.
HRL wants to archive all races for future viewing on demand.
A robust data analytics solution is needed to gain insights into viewer behavior and preferences.
The solution must be highly available and scalable to handle spikes during race events.

Technical Requirements

Real-time data processing capability is needed to handle race telemetry data.
A scalable video streaming solution is needed to broadcast races worldwide.
Archival storage is needed for storing race videos for on-demand viewing.
An analytics solution is needed for analyzing viewer behavior and preferences.
The solution must be highly available and scalable to handle traffic spikes during races. ::: tip Service Level Objectives Business requirements typically demand these common type of SLOs.

High Availability SLO Always accessible.
Durability SLO Always kept.
Reliability SLO Always meeting workloads.
Scalability SLO Always fitting its workloads.

:::

Mountkirk Games

Business Requirements

Mountkirk Games develops and operates online video games.
They need a solution to handle high scores and player achievements.
They need to collect minimal user data for personalizing the gaming experience.
The solution must be globally available and provide low latency.
They are interested in Managed services which can automatically scale.

Technical Requirements

A globally available high score and achievement system is needed.
User data needs to be collected and processed in a privacy-compliant manner.
The system must provide low latency for a smooth gaming experience.
Managed services can be used to handle automatic scaling.

::: tip Global Up-to-Date Data Cloud spanner is the best option for an SQL based global records storage with a High Consistency SLO. :::

TerramEarth

Business Requirements

TerramEarth manufactures heavy equipment for the construction and mining industries.
They want to leverage their vast trove of IoT sensor data to improve their products and provide better service to their customers.
They want to move their existing on-premises data infrastructure to the cloud.

Technical Requirements

IoT data needs to be ingested and processed in real-time.
A robust data analytics solution is needed to derive insights from the sensor data
A migration plan is needed to move existing data and systems to the cloud.

::: tip Cloud Dataproc Cloud Dataproc is a cloud-based platform for processing large data sets. It is designed to be scalable and efficient, and to handle data processing workloads of all types. Cloud Dataproc is based on the open-source Apache Hadoop and Apache Spark platforms, and provides a simple, cost-effective way to process and analyze data in the cloud. :::

Data Management Business Requirements

Business requirements help us know what platforms to connect and how they will work. Those same requirements will tell us what data is stored, how often, for how long, and who and what workloads have access to it.

How Processed?

What is the distance between where the data is stored and where it is processed? What volume of data will be moved between storage and processing during an operation or set of operations? Are we using stream or batch processing?

The first question’s answer influences both the read and write times and the network costs associated with transferring the data. Creating replicas in regions nearer to the point of processing will increase read times, but will only decrease network costs in a ‘replicate one time, read many times’ situation. Using storage solutions with a single write host will not improve replication times.

The second questions’s answer influences time and cost as well. On a long enough timeline, all processes fail. Build shorter running processes and design reconnecting robust processes.

The third question’s answer and future-plans answer will influence how you perform batch processing. Are you going to migrate from batch to stream?

Style	Pros	Cons
Batch	tolerates latency, on time data	interval updates, queue buildup
Stream	realtime	late/missing data

::: tip If using VMs for batch processing, use preemptible VMs to save money. :::

How Long?

At what point does data lose business value? With email, the answer is never, people want their past emails, they want all their backed up emails delivered. But with other kinds of data, like last year’s deployment errors, lose certain levels of value as it becomes less actionable now.

You’ll have to design processes for removing less valuable data from persistent storage locations and stored in archival locations or deleted. How long data is stored for each set of data will have a great affect on an architectural design.

How Much?

The volumes of data and how it will scale up when business goals are met or exceeded need to be planned for or else there will be a dreaded redesign and unnecessary iterations.

Storage related managers will need to know the volume and frequency of data storage and retrieval so they can plan for their duties and procedures which touch your design.

::: tip Factors of Volume and Load The main factors that affect volume are the number of data generators or sensors. If you consider each process that can log as a sensor, the more you log the higher your volume in Cloud Logging, the higher the processing costs in BigQuery and so forth.

Number of hosts
Number of logging processes
Network Connectivity
Verbosity Configuration

:::

Compliance and Regulations

Many businesses are under regulatory constraints. For example, “Mountkirk” receives payment via credit cards. So they must be PCI compliant and financial services laws apply their receiving payment.

Health Insurance Portability and Accountability Act (HIPAA) is United States legislation that provides data privacy and security regulations for safeguarding medical information.
General Data Protection Regulation (GDPR) a set of regulations that member states of the European Union must implement in order to protect the privacy of digital data.
The Sarbanes-Oxley (SOX) Act a number of provisions designed to improve corporate governance and address corporate fraud.
Children’s Online Privacy Protection Act (COPPA) is a U.S. law that requires website operators to get parental consent before collecting children’s personal information online.
Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards designed to protect cardholders’ information.
Gram-Leach Bliley Act (GLBA) designed to protect consumers’ personal financial information held by financial institutions.

::: tip Compliance TLDR In the United States

SOX regulates financial records of corporate institutions.
HIPPA regulates US companies protecting consumer access and the privacy of medical data.
PCI DSS is a standard for taking credit cards which processing underwriters may require an e-commerce vendor to abide by.

In Europe

GDPR regulates information stored by companies operating in Europe for its protection and privacy.

:::

When we know what regulations apply to our workload it is easier to plan our design accordingly. Regulations can apply to jurisdictions like HealthCare or like the State of California. Operating within a jurisdiction means you’ll have to research your industry’s governance and what it may be subject to.

Privacy Regulations

Regulations on data slant toward protecting the consumer and giving them greater rights over their information and who it is shared with. You can review privacy policies per Country at Privacy Law By County

Architects not only need to comply with these laws, but kindle the the spirit of the law within themselves, that of protecting the consumer. Architects need to analyze each part of their design and ask themselves how is the consumer protected when something goes wrong?

Access controls need to cascade in such a way that permissions are restrictive and then opened, and not the other way around. Data needs to be encrypted at rest and in transit and potentially in memory. Networks need firewall and systems need verification of breaches through logging. One can use the Identity Aware Proxy and practice Defense in Depth.

Data Integrity Regulations

The Sarbanes-Oxley (SOX) Act aims to put controls on data that make tampering more difficult. I worked for a SOX compliant business, IGT PLC and we had to take escrow of code, making versions of code we deployed immutable so it could be audited. In this case, tampering with the data was made more difficult by using an escrow step in the data processing flows. Other business might need to store data for certain number of years while also being immutable or having some other condition applied to it.

Security

IS, information security, infosec or cybersecurity is the practice or discipline of keeping information secure. Secured information as a business need comes from the need for confidentiality, the need for lack of tampering, and availability. Unavailable systems are generally secure. No can remotely compromise a computer, for instance, that has no network interface.

Confidentiality

Businesses need to limit access to data so that only the legal, ethical and appropriate parties can read, write, or audit the data. In addition to compliance with data regulations, competing businesses have a need to keep their information private so that competitors cannot know their trade secrets, plans, strategies, and designs.

Google cloud offers several options for meeting these needs. Encryption at rest and in transit is a good start. Memory encryption using N2D compute instances and shielded VMs make the system the least compromisable.

Other offerings include Google Secret Manager, Cloud KMS for keeping Google from reading the data except for the least-access cases you let it. When using customer supplied keys, they are stored outside of Google’s own key management infrastructure.

Protected networks keep data confidential. Services also can be configured for maximum protection. For instance, consider these apache configuration directives:

ServerTokens Prod
ServerSignature Off
<Directory /opt/app/htdocs>
  Options -Indexes
</Directory>
FileETag None

Similar directives in other service configuration make confidential your software versions and system software. In fact, turning ServerTokens and ServerSignature off and prod is a PCI DSS requirement.

Determine the methods of authentication how methods of authorization can compromise confidentiality.

::: tip Dealing with Inconsistent Message Delivery Cloud Pubsub is a messaging service that allows applications to exchange messages in a reliable and scalable way. It is a fully managed service that can be used to build applications that require high throughput and low latency.

If Applications are working synchronously, decouple them and have the reporters interact with a third services that is always available and that autoscales. :::

Integrity

Data Integrity is required by regulations which focus on making data tamper-proof, but normally is simply a business requirement. You need your records to be consistent and reflect reality. Data Integrity is also about keeping it in that state.

Ways in Google cloud that you can promote and increase data integrity are to use ways to promote data integrity in Google cloud are to use tools like Data Loss Prevention (DLP) and Data Encryption. You should also enforce least privilege, use strong data encryption methods, and use access control lists.

Colocate report data instead of drawing on active data. That way, if data is tampered with discrepancies exist directly within the app. The search for these discrepancies can be automated into their own report.

Availability

DDos attacks, ransomware, and disgruntled administrators and bad faith actors threaten the availability of data.

You can combat ransomware with a well hardened IaC(Infrastructure as Code) pattern culling resources which have their availability degraded, restoring their data and stateful information from trusted disaster recovery provisions.

When designing a project, design around these scenarios to ensure a business can survive malicious activity. Design a project which can not only survive a malicious attack but one that can also continue to be available during one.

::: tip Keeping Data Entirely Secret Cloud KMS is a cloud-based key management system that allows you to manage your cryptographic keys in a secure, centralized location. With Cloud KMS, you can create, use, rotate, and destroy cryptographic keys, as well as control their permissions. Cloud KMS is integrated with other Google Cloud Platform (GCP) services, making it easy to use your keys with other GCP products.

When you manage the encryption keys Google uses to encrypt your data, the data is kept secret from anyone who doesn’t have access to decrypt it, which requires access to uses those keys. :::

Success Measures

As businesses move to agile continuous deployment and integration, they want to see reports of the deployments going well, development costs decreasing, the speed of development therefore increasing. Amid all of this the want to measure the overall success of an endeavor so they can correctly support the resources which will increase the bottom line.

::: tip Continuous Integration & Delivery The benefits of CICD to business requirements is that it enables smaller incremental trunk-based development. This shortens the feedback loop, reduces risks to services during deployment, increases the speed of debuging, isolates featuresets to known risks. :::

Key Performance Indicators

The first to two important measurements is Key Performance Indicators(KPIs). The other is Return on Investment(ROI). KPIs measures of value of some portion of business activity which can be used as a sign things are well and an effort is achieving its objectives. A KPI for an automation team of reliability engineers might be a certain percentage as a threshold of failed deployments to successful ones.

Project KPIs

Cloud migration projects have KPIs which the project manager can use to gauge the progress of the overall migration. Another KPI might be having a set of databases migrated to cloud and no longer being used on premises. KPIs are particular to a projects own needs.

::: tip Improving SQL Latency Export unaccessed data older than 90 days from the database and prune those records. Store these exports in Google Cloud Storage in Coldline or Archive class buckets. :::

Operations KPIs

Operations departments will use KPIs to determine if they are handling the situations they set out to address. Product support teams can use KPIs to determine if they are helping their customers use their product to the degrees which mean the business objectives. Cloud Architects will need to know which KPIs will the used to measure the success of the project being designed. The help the architect understand what takes priority and what motivates decision-makers to invest in a project or business effort.

::: tip Total Cost of Ownership When Managers and Directors Only Compare Infrastructure Costs Calculate the TCO of legacy projects against planned cloud projects. Calculate the potential ROI with regard to the TCO of the investment. Use this wider scope to compare the true cost of running legacy projects or forgoing cloud migrations. :::

Return on Investment

Return on investment is the measure of how much of a financial investment pays off. ROI is a percentage that measures the difference between the business before and after the investment. The profit or loss after an investment divided by the total value of the investment. So:

$ROI=\left(\frac {investment\ value-cost\ of\ investment} {cost\ of\ investment} \right) \times 100$

Lets work this out for a 1 year period. Host U Online bought $3000 in network equipment and spent $6000 to migrate to fiber. The total cost of investing in fiber was $9000. They began reselling their fiber internet to sublets in the building. In one year the acquire six customers totalling $12,000 per month. A year’s revenue from the investment is $144,000.

$\left(\frac {135000} {9000} \right) \times 100 = 1500%$

This is a real scenario I orchestrated for a real company. Our return on investment, the ROI, was a tremendous 1500%.

In a cloud migration project the investment costs includes costs Google cloud services and infrastructure, personnel costs, and vendor costs. You should include expenses saved in the value of the investment.

::: tip Reducing Costs When designing for cost reduction, there are three options you should strongly consider:

The goals and concepts that the organization places high value upon will be underlying the KPIs and ROI measures.

Essentials

Understanding the sample requirements word for word
Knowing the meanings of business terms like TCO, KPI, ROI
Learn about what Google services are for what use cases
Understanding managing data
Understanding how compliance with law can affect the architecture of a solution
Understand the business impetus behind the aspects of security pertaining to business requirements
- Confidentiality
- Integrity
- Availabiltiy
Understand the motives behind KPIs

Official Resources

List of All Managed Google Cloud Platform(GCP) Services

Sep 13, 2022

Christopher Shaun Godwin

Author

Service	Type	Description
AutoML Tables	AI and Machine Learning	Machine learning models for structured data
Recommendations AI	AI and Machine Learning	Personalized recommendations
Natural Language AI	AI and Machine Learning	Entity recognition, sentiment analysis, language identification
Cloud Translation	AI and Machine Learning	Translate between two languages
Cloud Vision	AI and Machine Learning	Understand contents of images
Dialogflow Essentials	AI and Machine Learning	Development suite for voice to text
BigQuery	Analytics	Data warehousing and analytics
Batch	Compute	fully managed batch jobs at scale
VMware Engine(GCVE)	Compute	running VMware workloads on GCP
Cloud Datalab	Analytics	Interactive data analysis tool based on Jupyter Notebooks
Data Catalog	Analytics	Managed and scalable metadata management service
Dataproc	Analytics	Managed hadoop and Spark service
Dataproc Metastore	Analytics	Managed Apache Hive
Cloud Composer	Analytics	Data workflow orchestration service
Cloud Data Fusion	Analytics	Data integration and ETL tool
Data Catalog	Analytics	Metadata management service
Dataflow	Analytics	Stream and Batch processing
Cloud Spanner	Database	Global relational database
Cloud SQl	Database	Regional relational database
Cloud Deployment Manager	Development	Infrastructure-as-code service
Cloud Pub/Sub	Messaging	Messaging service
Bigtable	Storage	Wide column, NoSQL databases
Cloud Data Transfer	Storage	Bulk data transfer service
Cloud Memorystore	Storage	Managed cache service using Redis or memcached
Cloud Storage	Storage	Managed object storage
Cloud Filestore	Storage	Managed shared files via NFS or mount
Cloud DNS	Networking	Managed DNS with API for publishing changes
Cloud IDS	Networking	Intrusion Detection Systems
Cloud Armor Managed Protection Plus	Networking	DDos Protection with Cloud Armor’s AI adaptive protection
Service Directory	Networking	Managed Service registry
Cloud Logging	Operations	Fully managed log aggregator
AI Platform Neural Architecture Search (NAS)	AI Platform	AI Search
AI Platform Training and Prediction	AI Platform	NAS training
Notebooks	AI Platform	JupyterLab environment
Apigee	API Management	API Gateway security and analysis
API Gateway	API Management	API Gateways
Payment Gateway	API Management	integration with real-time payment systems like UPI
Issuer Switch	API Management	user transactor deployment
Anthos Service Mesh	Hybrid/Multi-Cloud	devide up gke traffic into workloads and secure them with istio
BigQuery Omni	Analysis	Use BigQuery to query other clouds
BigQuery Data Transfer Service	Analysis	Migrate data to BigQuery
Database Migration Service	Storage	fully-managed migration service
Migrate to Virtual Machines	Migration	migrate workloads at scale into Google Cloud Compute Engine
Cloud Data Loss Prevention	Security and Identity	discover, classify, and protect your most sensitive data
Cloud HSM	Security and Identity	Fully managed hardware security module
Managed Service for Microsoft Active Directory (AD)	Identity & Access	Managed Service for Microsoft Active Directory
Cloud Run	Serverless Computing	Run serverless containers
Cloud Scheduler	Serverless Computing	cron job scheduler
Cloud Tasks	Serverless Computing	distributed task orchestration
Eventarc	Serverless Computing	Event rules between gcp services
Workflows	Serverless Computing	reliably execute sequences of operations across APIs or services
IoT Core	Internet of Things	Collect, process, analyze and visualize data from Iot devices in real time
Cloud Healthcare	Healthcare and Life Sciences	send, receive, store, query, transform, and analyze healthcare and life sciences data
Game Servers	Media and Gaming	deploy and manage dedicated game servers across multiple Agones clusters

Official Resources

Designing and Planning Solutions in Google Cloud with GCP Architecture

Sep 12, 2022

Christopher Shaun Godwin

Author

Key Considerations

Business Use Case & Product Strategy
Cost Optimization
Dovetail with Application Design
Integration with External Systems
Movement of Data
Planning decision trade-offs
Build, buy, modify, deprecate
Measuring Success
Compliance and Observability

Collecting & Reviewing Business Requirements

Architects begin by collecting business requirements and other required information. Architects are always solving design patterns for the current unique mix of particular business needs. So every design is different. Because of this, you cannot reuse as a template a previous design even if it solved a similar use case.

Operational Topology

This unique mix of business requirements and needs is what we’ll call the Operational Topology. An Architect begins their work by making a survey of this landscape.

The peaks and valleys, inlets and gorges of this topological map include things like:

Pressure to reduce costs.
Speeding up the rate at which software is changed and released.
Measuring Service Level Objectives(SLOs)
Reducing incidents and recovery time.
Improving legal compliance.

::: tip Incident An incident is a period of time where SLOs are not met. Incidents are disruptions in a service’s availability therefore becoming degraded. :::

Reducing Capital Expenditures

The use of Managed services places certain duties on specialized companies who can reduce the cost of management by focusing on that discipline’s efficiency. This enables your business to consolidate its focus on its trade and products.

Managed services remove from an engineering team’s focus those concerns such as provisioning setup, initial configuration, traffic volume increases, upgrades, and more. If planned properly, this will reduce costs but those projections need to be verified. Workloads need to be separated in scope of their availability requirements. Workloads that don’t need highly available systems can use preemptive workloads. Pub/Sub Lite trades availability for cost. Auto-scaling and scaling down to zero, for instance, enable cost savings in tools like Cloud Run and App Engine Standard. Compute Engine Managed Instance Groups will scale up with load and back down to their set minimum when that load subsides.

Accelerating Development

We want to accelerate all development to a speed of constant innovation, the CI/CD singularity. This is what success means. Again, using Managed Services enables this by letting developers and release engineers focus on other things besides infrastructure management. The services Google hosts and manages and offers allows developers without domain expertise in those fields to use those services.

Continuous Integration and Deployment enable quick delivery of minor changes so that reviews can be quick and tracked work can be completed like lightning. Automated testing and reporting can be built into these delivery pipelines so that developers can release their own software and get immediate feedback about what it is doing in development and integration environments.

However, sometimes there are tacit business requirements that prevent you from using one of these solutions on every asset a business needs to maintain. You may be tasked to architect solutions around an ancient monolithic service which cannot be delivered to production in an agile manner. Planning to get out of this situation is your job and selling that plan to decision makers is also your goal. You have to believe in your designs and be an optimist that these specifications are all that is needed to meet the Operational Topology.

You may break apart the giant macroservice into microservices, but even if you do, that’s the future, what to do now? Do you rip and replace, meaning rebuild the app from scratch? Do you lift and shift, bring the macroservice into a compute engine while moving to microservices later. Finally, you could convert to microservices as you move it into cloud striking a hybrid between the two. Business requirements will point the way to the correct solution every time without fail.

Reporting Service Level Objectives(SLOs)

An application’s requirements which surround how available it needs to be to those whom it serves is called Service Level Objectives. Accounting systems might not need to be running except during business hours, while Bill pay applications that customers use will need to always be available. These two different systems used by two different audiences needs two different Service Level Objectives.

SLOs specify things like uptime, page load time. These events are recorded within Cloud Logging. When they are not met Alerts can be created with Cloud Monitoring. The data points in these logs are called Service Level Indicators(SLIs). An SLO is a formal definition of a threshold which SLIs need to stay compliant with.

Incident Recovery-time Reduction

When services become unavailable or degrades, an Incident has occurred. A Business’s response to an incident may vary from company to company, but for the most part, every company has some sort of response system.

Collecting metrics and log entries along the way reduce the time it takes to recover from incidents because it illuminates the states of parts of the system when the error occurred. The first thing a reliability engineer does is look at logs on a problematic system. If one can see all logs from all components in one place at the same time one can better put together a complete story rather than having to revise the story continually as the information about the problem is discovered.

Compliance and Regulations

The Big five most architects have to worry about are:

Health Insurance Portability and Accountability Act(HIPPA), a healthcare regulation
Children’s Online Privacy Protection Act (COPPA), a privacy regulation
Sarbanes-Oxley Act(SOX), a financial reporting regulation
Payment Card Industry Data Standard(PCI), Compliance data regulation protection for credit card processing
General Data Protection Regulation(GDPR), a European Union privacy regulation

Compliance with these means controlling who has access to read and change the regulated data, how and where it is stored, how long it must be retained. Architects track and write schemes of controls which meet these regulations.

Capital Expenditure

Capital expenditures are funds used to purchase or improve fixed assets, such as land, buildings, or equipment. This type of spending is typically used to improve a company’s long-term prospects, rather than for day-to-day operations. Because of this, capital expenditures can be a significant financial decision for a business, and one that should not be made lightly.

Compliance

Implementation of controls on access, storage, and lifecycle of sensitive data.

Digital Transformation

Digital transformation is the process of using digital technologies to create new or improved business processes, products, and services. It can be used to improve customer experience, operational efficiency, and competitive advantage. In order to be successful, digital transformation must be driven by a clear strategy and executed with careful planning and execution.

Governance

Governance is the process by which organizations are directed and managed. It includes the creation and implementation of policies, the setting of goals, and the monitoring of progress. Good governance is essential for the success of any organization, as it ensures that resources are used efficiently and effectively. There are four main principles of good governance: accountability, transparency, participation, and inclusiveness. Accountability means that those in positions of authority are held accountable for their actions. Transparency means that information is readily available and accessible to those who need it. Participation means that all stakeholders have a say in decision-making. Inclusiveness means that all voices are heard and considered. These principles are essential for the success of any organization.

Key Performance Indicators(KPI)

A key performance indicator (KPI) is a metric used to evaluate the success of an organization or individual in achieving specific goals. KPIs are often used in business to track progress and compare performance against objectives. While there are many different KPIs that can be used, some common examples include measures of sales, profitability, productivity, customer satisfaction, and safety.

Line of Business

A line of business (LOB) is a group of products or services that are related to each other. Businesses often have multiple lines of business, each with its own set of customers, products, and services. For example, a company that sells both cars and trucks would have two lines of business: automotive and commercial vehicles. Lines of business can be created for different reasons. Sometimes, businesses create lines of business to take advantage of different market opportunities. Other times, businesses create lines of business to better serve their customers’ needs. Lines of business can be a helpful way for businesses to organize their products and services. By creating lines of business, businesses can more easily target their marketing and sales efforts.

Operational Expenditures

Operational expenditures are the costs associated with running a business on a day-to-day basis. They can include everything from rent and utilities to payroll and inventory costs. For many businesses, operational expenditures are the largest category of expenses. Managing operational expenditures is a key part of running a successful business. Careful planning and budgeting can help keep costs under control and ensure that the business is able to generate enough revenue to cover all of its expenses. Operational expenditures can have a major impact on a business’s bottom line. Therefore, it is important to carefully track and manage these costs. Doing so can help ensure that the business is able to remain profitable and continue to grow.

Operating Budget

An operating budget is a financial plan that details how a company will generate and spend revenue over a specific period of time. The operating budget is important because it ensures that a company has the resources it needs to meet its operational goals. The budget also provides a way to track actual results against desired outcomes.

Service-Level Agreement(SLA)

A service level agreement (SLA) is a contract between a service provider and a customer that specifies the nature and quality of the service to be provided. The SLA will typically include a description of the service to be provided, the standards that the service must meet, the customer’s responsibilities, and the service provider’s obligations. The SLA may also specify the remedies available to the customer if the service provider fails to meet the agreed-upon standards.

Service-Level Indicators(SLI)

Service-level indicators (SLIs) are performance metrics that help organizations measure and track the quality of their services. SLIs can be used to track the performance of individual service components, as well as the overall performance of the service. Common service-level indicators include uptime, response time, and error rates. By tracking SLIs, organizations can identify service problems early and take steps to improve the quality of their services.

Service-Level Objectives(SLO)

Service-level objectives (SLOs) are a key component of any effective service-level management (SLM) program. SLOs help ensure that services are delivered in a consistent and predictable manner, and help identify and track the key performance indicators (KPIs) that are most important to the success of the business.

SLOs should be designed to meet the specific needs of the business, and should be based on a thorough understanding of the customer’s requirements. They should be realistic and achievable, and should be reviewed and updated on a regular basis.

An effective SLM program will help to ensure that services are delivered in a timely and efficient manner, and that customer expectations are met or exceeded.

Analyzing Technical Requirements

Technical requirements specify the characteristics that a system or component must have in order to be able to perform its required functions. These include requirements such as atomicity, consistency, reliability, and durability. Atomicity refers to the ability of a system to guarantee that a transaction is either completed in its entirety or not at all. Consistency refers to the ability of a system to maintain data integrity. Reliability refers to the ability of a system to perform its required functions correctly and consistently. Durability refers to the ability of a system to maintain data integrity in the face of failures.

Functional Requirements

Functional requirements are the specific capabilities that a system must have in order to perform its intended functions. For example, a compute requirement might be the ability to process a certain amount of data within a certain time frame, while a storage requirement might be the need for a certain amount of space to store data. Network requirements might include the need for certain bandwidth or the ability to connect to certain types of devices. All of these requirements must be taken into account when designing a system.

Cloud Compute Engine

Requirements can be grouped into being met by the cloud’s offerings. Compute Engine, App Engine, Kubernetes Engine, Cloud Run, and Cloud Functions all solve unique use cases. It is forseeable that all of your requirements are going to fall along these lines when it comes to processing data requests, responding to requests, delivering content and interfaces. If not, another Google product will represent a Functional Needs subset.

Cloud Storage

Similarly, storage options are plethora. One or more of them meet our needs. Is your data Structured, or Unstructured, Relational? What latency requirements do you have? Group your requirements together and look at how the offerings meet those needs. If you are only appending dumps of data somewhere, you can chose a better option for that.

Cloud Networking Requirements

How many instances or nodes will you need? That number will affect how big your subnets will need to be. Can Firewall rules be allowed by service accounts? Do you have multiple workloads that you can sort into different groups to which the rules correspond?

Do you need DNS peering to enable hybrid-cloud networking between your VPC and your on-premises networks? These are questions an architect asks. You have to take the company’s subnets into account so that you can avoid collisions. So is automated or custom subnetting right for your project?

How is hybrid peering accomplished: VPN Peering which has high security but low througput? Or will Dedicated Interconnect and Partner Interconnects be used at higher cost for greater throughput?

Nonfunctional Requirements

Nonfunctional requirements are those that specify system characteristics such as availability, reliability, scalability, durability, and observability. They are often expressed as quality attributes or service level agreements. Functional requirements define what the system does, while nonfunctional requirements define how the system behaves. Nonfunctional requirements are important because they ensure that the system will meet the needs of its users.

Availabiltiy
Reliability
Scalability
Durability
Observability

Availability Requirements

There are many factors to consider when determining the availability requirements for a system. The first is the required uptime, which is the percentage of time that the system must be operational. For example, a system with a required uptime of 99% must be operational for at least 99% of the time. Other factors include the reliability of the components, the redundancy of the system, and the response time to failures. Availability requirements are often specified in terms of uptime and downtime, which is the amount of time that the system is operational and unavailable, respectively.

Reliability Requirements

Reliability requirements are those that specify how often a system or component must perform its required functions correctly. They are typically expressed as a percentage or a probability, and they may be specified for a single function or for the system as a whole. Reliability requirements are important because they help ensure that a system will be able to meet its operational objectives. Related to Availability, Reliability is the same requirement under the pressure of business load.

Scalability Requirements

Scalability requirements are those that dictate how well a system can cope with increased loads. They are typically expressed in terms of throughput, response time, or capacity. For example, a system that can handle twice the number of users without any degradation in performance is said to be scalable.

Scalability is a key consideration in the design of any system, be it a website, an application, or a network. It is especially important in the case of web-based systems, which are often subject to sudden and unexpected spikes in traffic. A system that is not scalable will quickly become overloaded and unable to cope, leading to a poor user experience and potential loss of business. Scalability requirements often are linked to Reliability factors.

Durability Requirements

In order for a product to be considered durable, it must be able to withstand repeated use and exposure to the elements without showing signs of wear and tear. This means that the materials used to construct the product must be of high quality and able to withstand regular use. Additionally, the product must be designed in a way that minimizes the likelihood of damage. For example, a durable product might have reinforced seams or be made from waterproof materials. Ultimately, the durability of a product is a key factor in determining its overall quality and usefulness.

Durability in the cloud is the ability to retrieve data placed there in the future. This means not losing volumes, files, objects and the immediate replacability and reproducibility of any resources that are not functioning correctly.

Observability Requirements

Observability requirements are those that enable a system to be monitored and its performance to be assessed and internal states to be known. They are typically concerned with aspects such as the availability of data, the ability to detect and diagnose faults, and the ability to predict future behavior. In many cases, these requirements will need to be trade-offs between conflicting goals, such as the need for timely data versus the need for comprehensive data.