Cloud Concepts: Hybrid and Multicloud, Regions and Zones, IaaS vs PaaS vs SaaS (Cloud Digital Leader)

A cloud architecture describes where an organization's workloads run and who owns the infrastructure underneath them. The four terms on the Cloud Digital Leader exam are public cloud, private cloud, hybrid cloud and multicloud. Each answers a different business need, and the deciding detail in a scenario is almost always where the systems sit and how many providers are involved.

• Public cloud: a provider such as Google Cloud owns and runs the infrastructure and shares it securely among many customers, who rent capacity on demand.
• Private cloud: the cloud operating model (self-service, automation, pooled resources) on infrastructure dedicated to one organization, usually in its own data center.
• Hybrid cloud: a combination of on-premises or private infrastructure and at least one public cloud, working together.
• Multicloud: workloads spread across two or more public cloud providers.

The labels are not exclusive. An organization with its own data center, Google Cloud and a second public provider is both hybrid and multicloud, often called hybrid multicloud. Adding a second public cloud does not remove the hybrid label, and keeping a data center does not stop the estate from being multicloud.

Each architecture fits when its defining property is what the business needs. Read the scenario for the constraint that decides it.

Private cloud

A private cloud fits when isolation is the requirement: for example, a defense contractor whose policy forbids running a workload on hardware that any outside party also uses, but whose engineers still want to provision resources themselves through automated tooling. The price is ownership. The organization funds the hardware up front, maintains it, and can only use the capacity it has installed. If a ticketing site's traffic suddenly jumps to ten times its usual level, a private cloud cannot grow past the servers already in the racks, because there is no provider pool to draw on. Its ceiling is the hardware it owns.

Hybrid cloud

Hybrid cloud fits when some systems must or should stay on premises while others gain from the public cloud. Common reasons:

• Systems tied to a physical site, such as a hospital's imaging equipment or a store's checkout terminals that must keep working when the internet link drops, stay local while new analytics or AI workloads run in Google Cloud.
• Regulated or sensitive records stay in the organization's data center while new services use cloud capabilities.
• Bursting: a tax-preparation firm runs its everyday load on servers it already owns and rents cloud capacity only for the busy weeks before the filing deadline, instead of owning servers sized for one short period that sit idle the rest of the year.
• A gradual migration, where workloads move over time rather than all at once.

Multicloud

Multicloud fits when an organization wants to pick the best provider service for each workload, lower the risk of being locked in to one vendor, so that no single provider's pricing or product decisions can corner the business, or inherits a second provider through an acquisition. The price is more to run: each provider has its own consoles, skills, security controls and invoices for the organization to manage. Open standards and portable tools reduce that extra work, which is why openness matters to Google Cloud's hybrid and multicloud products (covered in the infrastructure and modernization lessons).

An IP (Internet Protocol) address is a numeric label that identifies a device or service on a network, so that traffic can be routed to it. DNS (the Domain Name System) is the lookup service that translates human-readable domain names, such as a company's web address, into those IP addresses.

Leaders should recognise two pairs of IP address kinds. An external (public) address is reachable from the internet, while an internal (private) address is used only inside a private network, such as a Virtual Private Cloud (VPC) network or an office network. An ephemeral address is assigned to a resource automatically and can change when the resource is stopped or recreated; a static (reserved) address is reserved by the organization and stays the same until it is released. A static address suits anything that must keep pointing at one fixed address, such as a DNS record or a partner's firewall allowlist. The kind of address decides how a resource is reached and whether its address stays the same. It has no effect on how fast traffic travels, so it is never a fix for latency.

When a customer types a web address, the browser first asks DNS for the matching IP address, then connects to that address. Only after the address is known do other services, such as a load balancer or a content delivery network, take part. IP addressing is the thing being looked up; DNS is the lookup.

Google Cloud's managed DNS service is Cloud DNS. It answers name lookups from Google's infrastructure, so an organization gets a highly available, scalable DNS service without running DNS servers itself. Keep it apart from similar-sounding products:

DNS or IP problems usually stop a connection from being made at all (the name can't be found, or traffic reaches the wrong place). They don't make a working connection slow or low quality.

Latency is the delay for data to travel across a network, and it grows with distance. Bandwidth is how much data a connection can carry per second. They limit different kinds of work, and telling them apart is the core skill this bullet tests.

Two patterns are worth recognising. First, delay without any loss of quality points to latency. In a live online auction where the video is crisp but bids register a second late, the stream has all the capacity it needs; a bandwidth shortage would show up as a blurrier or stuttering picture instead. Second, work made of many sequential round trips is limited by latency even when it moves little data. A checkout page that calls a far-away pricing service dozens of times in turn waits a full round trip for each call, so the delays add up. Shortening the distance between the components helps; a wider link does not.

Google's global network is the private fiber backbone, including subsea cables, that links Google Cloud regions with a large number of edge points of presence around the world. It supports digital transformation by giving organizations global reach with low latency and high reliability, without building data centers or networks of their own.

A user's request enters Google's network at an edge location near the user, then travels across Google's private backbone to the region running the application, instead of crossing most of the distance over the public internet. The shorter public-internet leg means lower and more consistent latency. For the business this means:

• Serve customers worldwide with good performance from one or a few regions.
• Enter new markets quickly by deploying in regions close to them, rather than building facilities.
• Reliable traffic between regions, which rides Google's own backbone rather than the public internet.

Network reach complements the customer's own architecture choices rather than replacing them. Resilience still comes from how many zones and regions a workload is deployed across, and data location still comes from which regions the organization picks.

Network Service Tiers

Google Cloud offers two network service tiers that control how much of that path uses Google's backbone. Premium Tier (the default) brings traffic onto Google's network at the edge location closest to the user and carries it on the private backbone. Standard Tier is a lower-cost option in which traffic enters and leaves Google's network near the region, so it spends more of its journey on the public internet. For distant users of a single region, Premium Tier improves performance in a way that extra bandwidth or extra zones cannot.

A region is an independent geographic area, such as a metropolitan area, where Google Cloud runs its infrastructure. Each region contains several zones: deployment areas inside the region that are isolated from failures in the other zones. The hierarchy runs region, then zone; a zone never contains regions, and the two are not names for the same data center.

Where you place resources decides which failures they survive:

Adding more servers inside the same zone adds capacity, not resilience, because they share the zone's fate. Adding zones to a distant region improves availability but does nothing for latency.

Choosing a region is a balance of four factors: where the users are, what failures the workload must survive, where the data is allowed to live, and which products the region offers.

• Latency: run the workload in a region close to its users. An online tutoring platform whose students are in Brazil but whose servers run in Europe feels sluggish because latency grows with distance; a region in South America helps, and a bigger link does not.
• Resilience: if the application must keep running through a whole-region outage, it needs a second region.
• Data residency: laws or policies can restrict which regions qualify. When residency and regional resilience are both required, the backup region must satisfy the same rule. A health-records service that must keep data in Australia, for example, would pair two Australian regions rather than add a standby region overseas.
• Product availability: Google Cloud products are not offered in every region, and Google publishes availability by location. Check a candidate region against the products the workload depends on, alongside proximity, rather than letting either factor decide alone.

Edge locations (points of presence) are Google sites close to users where traffic enters Google's network and where content can be cached. They don't run an organization's main workloads; regions and zones do.

The components work together like this: a user's request reaches the nearest edge location, crosses Google's private backbone and is handled by the application running in a region's zones. With Cloud CDN, popular static content such as images and video is cached at edge locations, so repeat requests are answered nearby instead of travelling to the region.

Caching brings two benefits: faster delivery to viewers, and fewer requests reaching the origin servers in the region, which lowers their load and the traffic leaving the region. Caching helps only content that many users request in the same form. A banking dashboard that shows each customer their own balances gains little, because every response is unique. Caching also leaves the architecture underneath unchanged: where data is stored and how many zones the origin servers run in remain separate decisions. For distant users of personalized content, the levers are a better network path (Premium Tier) or a region closer to them.

Cloud service models describe how much of the technology stack the provider manages for the customer. Moving from IaaS to PaaS to SaaS, the customer manages less and gets faster results, and gives up control in return.

• Infrastructure as a Service (IaaS): the provider supplies virtual machines, storage and networking; the customer installs and manages the operating system and software. Google Cloud example: Compute Engine.
• Platform as a Service (PaaS): the customer deploys its own code and the provider runs the servers, operating system and runtime. Examples: App Engine and, for containerized applications, Cloud Run (Google describes it as a serverless container platform); Cloud Run functions run single functions in response to events or HTTP requests (sometimes called functions as a service).
• Software as a Service (SaaS): the provider delivers a finished application over the internet and runs everything behind it. Example: Google Workspace for email and documents.

Two scenarios show the logic. An accounting package from a vendor that has gone out of business installs only on one particular operating system release; IaaS fits, because a virtual machine can reproduce that environment without touching the software. A product team building a new customer-facing web service wants to deploy code and let the platform handle scaling and patching; PaaS fits. SaaS trades control for convenience: the provider decides how the product behaves and when new versions arrive for all customers, and each customer adjusts it only through the settings and extension points offered.

Models can be mixed per component. A media company might run its video-transcoding tool, which depends on custom drivers installed in the operating system, on virtual machines while its web front end runs on a PaaS. Only the component that truly needs OS control takes on server maintenance.

Responsibility shifts from customer to provider layer by layer as you move from IaaS to SaaS, but two ends never move: the provider always runs the physical data centers, and the customer always owns its data and decides who can access it.

So the responsibilities that move from customer to provider between IaaS and SaaS are the middle of the stack: patching the operating system and updating the application. Even with a SaaS suite like Google Workspace, the company still decides what information goes into it and sets the sharing permissions for its people. Compared with any cloud model, running on premises adds the most management of all, since the organization also owns the hardware.