Good Morning, Bhavesh!

I’m Aman, and I’m currently a Google Cloud Platform trainer at Koenig
Solutions. I specialize in helping individuals leverage the power of cloud computing for scalable,
secure, and innovative solutions.

Before stepping into cloud training, I spent a year working in the Generative AI space. During
that time, I had the opportunity to work on advanced model training projects, including working
with models like Gemini—where I focused on optimizing them for software code understanding
and generation. This gave me a deep insight into how AI can transform the way we build and
interact with software. So, that’s it for my introduction.

Let’s know something about you Bhavesh!

[0:00–5:00] Introduction

Today, we’ll explore essential cloud infrastructure components and how they power today’s AI
and machine learning workloads. Our agenda covers:

1. Compute Services (IaaS, Containers, Serverless)

2. Specialized AI Hardware known as TPUs

3. Storage Services

4. Choosing the Right Database for your needs

Feel free to ask questions at any point!

So, Let’s start with Google Cloud Infrastructure:

Google Cloud is structured into three core layers:

• Layer 1: Networking & Security – powered by Google’s global private fiber

network with built-in security, identity management, encryption, VPC networking which basically
provides a private network environment isolated within Google Cloud, allowing secure
and flexible resource management and finally DDoS Protection which means protection of
your infrastructure from DDoS attacks by absorbing and filtering malicious traffic.

•Layer 2: Compute & Storage – Google cloud provides separate, independently

scalable compute and storage services (VMs, containers and serverless platforms).

VMs (Virtual Machines): Software-based emulation of physical computers, allowing

users to run different operating systems and applications.

Containers: Lightweight, isolated environments for running applications, encapsulating

all dependencies needed for execution.
 •Layer 3: Data & AI/ML - Google cloud also provide tools such as Pub/Sub for
messaging, Dataflow for processing, BigQuery for analytics, Vertex AI for ML, and Looker for
data insights.

Finally, we have TPU’s which are built in hardwares in google cloud which we will discuss later
on.

Now lets talks about all of them in more details, starting with compute Engine:

Google Cloud offers multiple compute services tailored to different application needs:

•Compute Engine (IaaS): Google cloud provides “Infrastructure as a Service” in form of

Computer Engines providing full control of virtual machines, customizable resources, per-
second billing, and supports GPUs/TPUs.

Let’s talk about containers:

•Google Kubernetes Engine (GKE): A managed Kubernetes service for container

orchestration, automating container deployment, scaling, and management—perfect for
microservices architecture, which breaks down applications into small, independently
deployable services.

Then we have Cloud Run,

•Cloud Run is a platform running stateless containers, automatically scaling to zero, when not
needed. Now, ‘Stateless’ actually means that each container instance doesn’t retain data or
state between requests, which simplifies scaling and ensures consistency. Cloud Run also
abstracts away all infrastructure management—there’s no need to provision or manage servers.
It launches instances in response to HTTP requests and scales them down when idle, which
makes it highly cost-effective for unpredictable workloads. This makes it perfect for deploying
APIs, microservices, or webhook endpoints with variable or spiky traffic.

Other servies from google cloud, includes:

•App Engine (PaaS): Fully managed platform abstracting runtime management, auto-scaling,
integrated services—best suited for rapid application development.

•Cloud Functions (FaaS): Event-driven, fully serverless functions triggered by HTTP, Pub/Sub,
or Cloud Storage events—great for lightweight backend processes. For example, you can use a
Cloud Function to automatically resize images uploaded to Cloud Storage, respond to API
requests from a web app, or process Pub/Sub messages that trigger downstream workflows
such as sending notifications, transforming data, or logging events. This is ideal for event-
handling logic that doesn’t require maintaining a server or complex infrastructure.
[Enter]

Let’s now talk about some hardware: TPUs

Before TPUs, Google used GPUs and CPUs for ML workloads, but as models like Google
Translate and later deep learning models scaled up, those processors couldn’t keep up with the
performance and energy efficiency demands. Google needed a custom solution that could
accelerate tensor-heavy operations—specifically matrix multiplications used in training and
inference—while being cost and power-efficient.

[Enter]

Google’s TPUs (Tensor Processing Units) are custom ASIC chips (Application-Specific
Integrated Circuits designed specifically for particular computing tasks) optimized specifically for
tensor operations central to ML workloads. TPUs provide:

•Up to 30 times faster processing compared to GPUs and around 80% greater energy
efficiency.

•Available as single TPU chips or scalable TPU pods.

•Integrated seamlessly with ML frameworks like TensorFlow and PyTorch through XLA
compilers. XLA (Accelerated Linear Algebra) is a domain-specific compiler for linear algebra
that optimizes TensorFlow and PyTorch models to run efficiently on Google’s TPUs. Instead of
interpreting each operation at runtime, XLA compiles entire subgraphs of the model into
optimized TPU-executable code, reducing execution overhead and boosting performance.

Use TPUs primarily for large-scale ML model training and intensive inference tasks like natural
language processing (BERT models) and vision tasks.

[38:00–48:00] Storage Services & Tiering

Google Cloud separates storage from compute, i.e decoupled Storage, enabling independent
scalability and cost optimization:

Unstructured Data services:

•Cloud Storage (Unstructured Data): A highly durable and scalable object storage service
designed for images, videos, backups, and raw data.

•Standard: For frequently accessed data (hot storage), such as active datasets or media
for streaming.

•Nearline: Best for data accessed around once per month, such as monthly reports.

•Coldline: Suitable for infrequently accessed data—like quarterly audit logs.

 •Archive: Ideal for long-term archival storage, like compliance records or historical
backups.

Structured Data Services:

•Cloud SQL: A fully managed relational database service supporting MySQL,

PostgreSQL, and SQL Server. Great for regional workloads that require transactional
consistency and compatibility with existing SQL applications.

•Spanner: A globally distributed, strongly consistent relational database. Combines the

best of traditional SQL (ACID compliance, joins, schema) with horizontal scalability—ideal for
global financial or inventory systems.

•Firestore: A NoSQL document database designed for web and mobile apps. Offers
real-time updates and offline sync, with flexible document schema and scalability from regional
to global.

•BigQuery: A serverless, highly scalable, and cost-effective multi-cloud data warehouse.

Used for OLAP workloads—ad hoc queries, dashboards, and business intelligence over
petabyte-scale datasets.

•Bigtable: A wide-column NoSQL database for very large, low-latency workloads. Often
used in time-series data, IoT telemetry, and real-time analytics. It offers high write throughput
and integrates with tools like Dataflow and BigQuery.

These services are designed to support diverse data models—SQL for structured relationships
and NoSQL for schema flexibility and scale—based on access patterns, scalability needs, and
consistency requirements.

[48:00–58:00] Choosing the Right Database

Your database choice depends on workload type (transactional vs analytical), schema flexibility,
and scale:

Difference between SQL and NoSQL Databases:

Aspe SQL (Relational) NoSQL (Non-relational)

ct

Data Tables of rows & Documents, key-value pairs,

mod columns (fixed wide-column, graphs (flexible
el schema) schema)

Sche Predefined: columns Dynamic: each record can have its

ma and types must be own structure
declared up front
 Quer Structured Query Varies by product (e.g. MongoDB’s
y Language (SQL) JSON-style queries, Cassandra CQL,
lang Redis commands)
uage

Join Built-in support for Typically no joins; relationships

s& joining tables handled in application or via
relati embedded documents
ons

Tran Strong ACID Varies: many offer “eventual

sacti guarantees consistency” or limited
ons (Atomicity, multi-document transactions
Consistency,
Isolation, Durability)

Scali Vertically (bigger Horizontally (add more

ng single server) servers/nodes)

Use • Complex queries & • Large-scale, high-throughput apps•

case reporting• Financial Real-time analytics• Flexible or
s systems• Strict evolving data models
consistency needs

Exa MySQL, PostgreSQL, MongoDB, Cassandra, Redis,

mple Oracle, SQL Server Couchbase, Neo4j
s

Transactional (OLTP - Online Transaction Processing):

• Optimized for rapid, small transactions.

• Ensures data integrity with ACID properties (Atomicity, Consistency, Isolation,

Durability).

1. Atomicity: This property ensures that all operations within a transaction are treated as a
single, indivisible unit. Either all operations within a transaction are completed successfully, or
none of them are. If any operation fails, the entire transaction is rolled back to its original state,
ensuring data integrity.

2. Consistency: This property guarantees that the database always transitions from one valid
state to another during a transaction. It enforces the rules and constraints of the database,
ensuring that all operations within a transaction adhere to these rules. For example, a bank
transfer transaction must ensure that the amount debited from one account is also credited to
another, maintaining the integrity of the overall balance.

3. Isolation: This property ensures that concurrent transactions do not interfere with each other.
Each transaction is isolated from other transactions, preventing one transaction from seeing the
intermediate states of another transaction. This isolation helps maintain data consistency and
prevents corruption caused by concurrent access.
4. Durability: This property ensures that once a transaction is committed, the changes are
permanent and will survive even in the event of system failures, such as power outages or
hardware malfunctions. The committed changes are stored reliably on the database, ensuring
data persistence and integrity.

Use cases: Payments, inventory, order management.

• Cloud SQL: Regional scale relational DB.

• Spanner: Global scale relational DB.

• Firestore: Flexible schema, NoSQL, supports web/mobile apps.

Analytical (OLAP - Online Analytical Processing):

• Optimized for complex queries and large-scale aggregations (summarizing large

volumes of data).

• Multidimensional analysis, reporting, trend analysis.

• BigQuery: Petabyte-scale data warehouse with SQL support.

• Bigtable: Ideal for high-throughput analytics, IoT, and time-series.

Considerations include SLAs (Service Level Agreements, formal commitments from service
providers specifying uptime, performance metrics, and penalties), consistency guarantees,
compliance needs, and cost.