Before touching a single console or typing a single command, it is worth understanding exactly what you are buying when you sign up for the cloud, which part of the work stops being yours and which part remains yours. This lesson builds that mental framework: what "cloud computing" means, how IaaS, PaaS and SaaS differ, what Google Cloud Platform specifically is and what infrastructure it rests on, which service families it offers and how they map onto the modules of this course, how it compares with AWS and Azure, and why the economics of the cloud (paying for what you use instead of buying hardware) change technical decisions. We will finish by introducing AlpinaShop, the online shop we will migrate step by step throughout the course and that will give context to every example and every exercise.

This is the most conceptual lesson in the course, and also the one that pays off the most: almost every expensive mistake made in the cloud is not a command mistake, but a mental-model mistake.

1. What cloud computing is
2. IaaS, PaaS and SaaS: who manages what
3. What Google Cloud Platform is and what it rests on
4. Catalogue of GCP service families
5. An honest comparison with AWS and Azure
6. The economics: CapEx versus OpEx
7. The AlpinaShop case: our starting point

Cloud computing means consuming computing resources —compute capacity, storage, networking, databases, AI models— as an on-demand service over the internet, instead of buying, installing and maintaining them yourself.

The classic definition (NIST's, still valid as a reference) identifies five essential characteristics. They are worth reading slowly, because each one has practical consequences:

• On-demand self-service: you can create a machine or a database without calling anyone or raising a ticket. Practical consequence: provisioning time goes from weeks to seconds, which is why governance stops being a formality and becomes critical (anyone can create spend).
• Broad network access: resources are consumed over the network with standard protocols (HTTPS, REST APIs). Consequence: everything you do in the console can also be done through an API, and therefore automated.
• Resource pooling: the provider shares an enormous infrastructure among many customers using virtualisation and isolation. Consequence: economies of scale, but also the need to understand isolation and multi-tenant security.
• Rapid elasticity: you can grow and shrink almost instantly. Consequence: sizing for the peak stops being compulsory.
• Measured service: everything is metered and billed by usage. Consequence: cost becomes just another engineering metric, like latency.

AlpinaShop will run a migration that starts out hybrid (for a few weeks the old server and GCP coexist) and ends up as pure public cloud. Hybrid connectivity and multi-cloud strategies are covered in module 7 (Anthos and advanced networking).

The distinction between service models is, at bottom, a line separating what the provider manages from what you manage. The higher you go, the less you control and the less you maintain.

Translated into specific Google Cloud services:

One important warning: "less management" does not mean "less responsibility". In every model you remain responsible for your data, for who accesses it and for the configuration you apply. A badly configured Cloud Storage bucket exposes data just as effectively when it is serverless. This division of duties is formalised in the shared responsibility model, which we will study in detail in lesson 01-05.

Google Cloud Platform (GCP) is the set of infrastructure and platform services that Google sells on top of the same physical infrastructure it uses for its own products: Search, YouTube, Gmail and Maps. That sentence, which sounds like a slogan, has three very concrete technical implications:

• A global private backbone network. Google operates its own fibre network between data centres and more than a hundred points of presence. When traffic enters a Google PoP (in Madrid, for example), it travels to your service over that private network, not over the public internet. This reduces latency and variability, and it is the basis for services such as the global load balancer and Cloud CDN (module 3).
• Its own data centres and bespoke design. Google designs its servers, its network switches and its chips (TPU for AI, Titan for boot security). Encryption of data at rest and in transit within its infrastructure is on by default, without you having to configure it.
• Technologies born for internal scale. Several GCP services are the commercial version of internal systems: BigQuery descends from Dremel, Cloud Bigtable from Bigtable, Pub/Sub from the internal messaging system, and Kubernetes is the open rewrite of Borg. They are not products conceived for the market and then scaled up: they were scaled first.

A useful point of naming from the outset: today Google mostly uses the "Google Cloud" brand for everything (including Workspace and the industry solutions), and "Google Cloud Platform" or GCP for the infrastructure and platform part we are concerned with. You will see both terms in the documentation; in this course we use them interchangeably to refer to the technical platform.

The Google Cloud catalogue runs to more than two hundred services, but it groups into a handful of families. You do not need to know them all: you need to know which family solves which problem so you can search within it.

Two remarks on naming, because you will come across old documentation using retired names:

• Cloud Monitoring, Cloud Logging and Cloud Trace are the current names of what was called Stackdriver for years.
• Vertex AI unified what used to be AI Platform and AutoML separately.
• Artifact Registry replaces Container Registry (gcr.io), which is deprecated.

If a tutorial you find online mentions Stackdriver, AI Platform or gcr.io, it predates 2022 and probably contains more out-of-date material.

The three big providers cover practically the same needs. The real differences are in the details of each service, in the pricing model and in the company's ecosystem, not in "which one can do X".

Where each one tends to stand out, marketing aside:

• Google Cloud has a recognised advantage in data analytics (BigQuery is genuinely serverless: you do not manage a cluster) and in Kubernetes, which is Google-originated technology. Its global network and its global load balancer with a single anycast IP are technically elegant. Its market share is third, which in practice means fewer professionals with hands-on experience and sometimes fewer third-party integrations.
• AWS has the broadest catalogue, the largest community and the most abundant third-party documentation. It also has the most accumulated complexity and a less coherent console.
• Azure dominates wherever there is already a heavy investment in Microsoft (Active Directory, .NET, Windows Server licences), with integration and licensing advantages that are hard to match in that context.

For AlpinaShop, with a Python application that has no Microsoft dependencies and an ambition to exploit its sales data, Google Cloud is a reasonable choice. It is not the only possible one, and saying so is a perfectly professional answer.

This is the change that most affects technical decisions, and the one that is least well understood at first.

The key concepts you need to internalise:

• Pay per use: you are billed for CPU seconds, gigabytes stored per month, gigabytes of outbound traffic, queries run. A resource that is switched off stops generating compute cost, but a persistent disk keeps costing money even while the VM is stopped. It is beginner mistake number one.
• Elasticity: capacity adjusts to demand. For AlpinaShop, whose traffic multiplies during the autumn campaigns, this means no longer paying all year round for capacity it only needs for six weeks.
• Committed use and sustained use discounts: Google automatically applies sustained use discounts to VMs that run for a large part of the month, and offers bigger discounts if you commit to 1 or 3 years. There are also Spot VMs, far cheaper in exchange for being interruptible.
• Egress cost: moving data into Google is free; taking it out to the internet is not. In architectures with a lot of download traffic (catalogue images, for instance) this line item matters.

A warning about figures. Prices, quotas and free tier details change frequently and vary by region. In this course we use figures only as orders of magnitude; always check the current amounts in the calculator and in the official Google Cloud pricing documentation before making a decision. Systematic cost optimisation is covered in lesson 07-05.

One nuance worth stating early: the cloud is not automatically cheaper. A stable, predictable, always-on workload can end up costing more in the cloud than on an already amortised server of your own. What the cloud really buys you is elasticity, speed of change and managed services that replace staff hours. If your workload takes advantage of none of that, the economic argument weakens.

Throughout the course we will work with a single case, so that every service we look at fits into an architecture that grows coherently.

AlpinaShop is a Spanish small business of around 40 people that sells mountaineering gear online: backpacks, boots and tents. Its corporate domain is alpinashop.example. The people we will be working with are:

• Marta, head of infrastructure. She leads the migration and will be the one creating projects, configuring networks and keeping an eye on billing.
• Dani, backend developer. He maintains the Flask application and deploys the changes.
• Lucía, data analyst. Today she lives inside a spreadsheet and wants to answer business questions with real data.

• A rented physical server at a traditional hosting provider, on an annual contract with fixed sizing.
• A single PostgreSQL instance on that same server, with the tienda database, and a daily backup to an external disk whose restore has never been tested.
• The web application is a Python catalogue built with Flask served by Gunicorn behind Nginx.
• The product images (some 60 GB and growing) sit on the server's local disk, served by that same Nginx.
• Analytics consists of exporting a monthly CSV from the database into a spreadsheet.

Over the course we will build this target architecture piece by piece. The names are fixed and you will meet them again in every module:

• Projects alpinashop-prod and alpinashop-dev, in the europe-west1 region (zone europe-west1-b).
• Bucket alpinashop-catalogo for the product images.
• Cloud SQL instance alpinashop-pedidos (PostgreSQL) with the tienda database.
• Cloud Run service alpinashop-web and GKE cluster alpinashop-cluster.
• Pub/Sub topic pedidos-nuevos and BigQuery dataset alpinashop_analitica.

In this lesson we have not created anything yet: we have established the why. In the next one we will open the account and put the first defences in place against nasty surprises on the bill.

• Believing that migrating means "standing up the same VMs in the cloud". A literal lift and shift reproduces in GCP exactly the same problems as before, and charges by the hour on top. It is a valid first step for reducing risk, but it is only a step: the value comes from replacing components with managed services.
• Confusing "managed" with "not my problem". The provider manages the infrastructure; your data, your permissions and your configuration are still yours.
• Assuming the cloud works out cheaper without doing the sums. Compare against the real workload, not the theoretical one, and include staff costs and egress traffic.
• Forgetting egress. Serving 60 GB of images to a lot of users generates billable outbound traffic. That is an argument in favour of a CDN, not against the cloud.
• Learning the catalogue by heart. Nobody knows two hundred services. Learn the families, and within each family the criteria for choosing. Lesson 02-07 is devoted precisely to those criteria for compute.
• Tip: think of cost as an engineering metric. Just as you review latency and errors, review spend. Seeing it early avoids painful redesigns.
• Tip: do not look for "the best provider". Look for the one that best fits your team, your stack and your regulatory requirements. All three work.

For each of these situations, say whether it corresponds to IaaS, PaaS, serverless or SaaS, and justify which part of the maintenance disappears from your to-do list:

1. Marta creates a virtual machine with Debian on which she will install PostgreSQL herself.
2. Dani deploys the Flask application packaged in a container and only specifies how much CPU it needs per request.
3. AlpinaShop signs up for Google Workspace for corporate email.
4. Marta creates a managed PostgreSQL instance and chooses the version, the size and the backup window.

For each of these three real AlpinaShop problems, name the family of GCP services that addresses it and the module of the course where it is covered. You do not have to get the exact service right: the aim is to reason by family.

1. During the autumn campaign the site takes 8 seconds to load and some customers abandon their basket.
2. Lucía needs to cross three years of orders with stock data to decide how much gear to buy.
3. When the site fails, nobody finds out until a customer writes in through the contact form.

AlpinaShop's current server costs €280 a month on an annual contract and is sized to withstand the autumn peak. For 10 months of the year it uses around 15 % of its CPU; for 6 weeks it saturates and the site degrades.

Without doing exact GCP price calculations (they change and have to be looked up), argue in five or six lines what economic and operational advantages a pay-per-use model with autoscaling would offer, and what new economic risk appears that did not exist before.

Solution 1

1. IaaS (Compute Engine). Google takes care of the hardware, the power, the physical network and the virtualisation. Marta remains responsible for the operating system, the patches, installing PostgreSQL, its backups and its high availability.
2. Serverless (Cloud Run). The operating system, the application server, the sizing and the scaling all disappear. Dani only maintains the container image and its configuration.
3. SaaS. No infrastructure task remains: only user administration and product configuration.
4. PaaS (Cloud SQL). Google manages the OS, installing the engine, the patches, the backups and failover. Marta remains responsible for the schema, the queries, the indexes and who has access.

Solution 2

1. The compute family (autoscaling) and the networking family (load balancing and CDN). Modules 2, 3 and 7. The cause may lie either in compute capacity or in how the images are delivered.
2. The data and analytics family, with BigQuery as the warehouse and Looker Studio to visualise. Module 4.
3. The DevOps and operations family: Cloud Monitoring for metrics and alerts, Cloud Logging for diagnosis. Module 6.

Solution 3

An indicative answer: today AlpinaShop pays all year round for capacity it only needs for six weeks, and even so that capacity turns out to be insufficient at the peak (paying too much and serving too little, which is the worst of both worlds). With pay per use and autoscaling, cost would roughly track demand: low in the quiet months and high only during the campaign, when it also coincides with maximum revenue, so that cost correlates with turnover. On top of that come operational advantages that are hard to price in euros but are real: the risk of running out of capacity at the worst possible moment disappears, and so do the server maintenance tasks.

The new risk is that spend no longer has a natural ceiling. A configuration error, a retry loop, a process that never shuts down or a spike of illegitimate traffic can send the bill through the roof without anyone explicitly authorising it. That is why budgets and billing alerts are configured on day one, not after the first scare: it is exactly what we will do in lesson 01-02.

In this lesson we have built the conceptual framework for the course. We have seen what cloud computing is and which five characteristics define it; how IaaS, PaaS, serverless and SaaS draw a movable line between what the provider manages and what you manage; what Google Cloud Platform is and why its global network, its own data centres and its internal technological heritage are technical arguments and not merely commercial ones; which service families exist and in which module of the course each is covered; how GCP compares with AWS and Azure without falling into fanaticism; and why the shift from CapEx to OpEx changes design decisions, with pay per use and elasticity as the central pieces and cost control as a new engineering responsibility.

And we have met AlpinaShop: its rented server, its single PostgreSQL, its 60 GB of images on a local disk and its autumn peaks that bring the site down. Marta, Dani and Lucía will accompany us in every lesson.

In the next lesson, Setting Up Your GCP Account, we move from theory to action: we will create the account, understand what the free tier really includes, see why a company like AlpinaShop needs Cloud Identity rather than personal accounts, create the billing account and the alpinashop-dev project, and configure budgets and alerts before switching anything on. We start building.