Cloud models: IaaS, PaaS, SaaS and shared responsibility

A week after the steering committee, Farah drew a stack of boxes on the whiteboard in Birchline's project room. At the bottom were the building, power and network; above them physical servers and storage; then virtualization, operating systems, middleware and runtimes, applications, and at the very top the data and the people who use it. "Every system we run needs all of these layers," she told Owen. "Today we look after every one of them ourselves. In the cloud, the question for each system is how many layers we want to hand to Google." The answer depends on the service model, and the service model decides who is responsible for what when something goes wrong.

This lesson covers the three classic service models, the deployment models that describe where cloud resources live, a few networking terms every digital leader should be comfortable with, and the shared responsibility model that ties them together. These ideas sit in the first section of the Cloud Digital Leader exam guide and come back in almost every scenario question.

Infrastructure as a service

In infrastructure as a service (IaaS), the provider supplies the basic building blocks: virtual machines, disks, networks and load balancers. The customer chooses the operating system, installs and patches it, and runs whatever software it likes on top. On Google Cloud, Compute Engine is the main IaaS product. IaaS gives the most control and the most familiar environment, which makes it the natural landing place for applications that are moved with few changes. It also leaves the customer with the most work: someone still has to patch the operating system, configure backups and plan capacity.

Birchline's store inventory system is a good IaaS candidate. It runs on a specific version of Windows Server with a vendor's software that cannot easily be changed. Moving it to virtual machines on Compute Engine lets Birchline retire the old hardware without rewriting anything. The trade-off is that Owen's team keeps every operating system task it has today, minus the hardware.

Platform as a service

In platform as a service (PaaS), the provider also runs the operating system, the runtime and much of the surrounding plumbing. The customer brings its application code and data, and the platform handles servers, scaling and patching. Google Cloud's PaaS and serverless offerings include Cloud Run, which runs containers without the customer managing servers, and managed databases such as Cloud SQL, where Google installs, patches and backs up the database engine. PaaS lets developers spend their time on features rather than servers, but the customer accepts the platform's rules: supported languages, configuration options and limits.

For Jules's online shop, the order API is a good fit for PaaS. The development team already packages it in a container, and Cloud Run can scale it from a handful of instances on a quiet Tuesday morning to many more during a sale. The product catalog database, MySQL today, can move to Cloud SQL, so no one at Birchline has to patch the database server again.

Software as a service

In software as a service (SaaS), the provider delivers a complete application over the internet. The customer configures it, manages its users and owns its data, but does not see servers, operating systems or code. Email and office suites such as Google Workspace, customer relationship management systems and payroll services are typical SaaS products. SaaS is the fastest way to get a capability and requires the least technical work, but it offers the least control. If the application does not do something, the customer usually cannot change it.

Birchline already uses SaaS without thinking of it that way. Its payroll runs on a SaaS service, and the staff scheduling tool the stores want is available as SaaS. Farah's rule of thumb for the committee was simple: if a good SaaS product does the job and Birchline gains no competitive advantage from building its own, buy the SaaS product and spend engineering time where it matters.

The models are not strict boxes. Many modern services fall between them, and Google often describes products such as BigQuery as serverless or fully managed: the customer never sees a server, pays according to use and lets Google handle scaling. For the exam, the useful habit is to ask how much of the stack the customer manages, then place the product on the scale from IaaS to SaaS.

Deployment models: public, private, hybrid and multicloud

Service models describe how much is managed for you. Deployment models describe where the computing runs and who can use it. A public cloud is run by a provider and shared by many customers, each isolated from the others; Google Cloud is a public cloud. A private cloud is cloud-style infrastructure dedicated to one organization, often in its own data center, offering self-service and automation but not the provider's scale. A hybrid cloud combines on-premises or private infrastructure with a public cloud, connected so that workloads and data can move between them. A multicloud approach uses more than one public cloud provider.

Birchline will be hybrid for at least a couple of years. The store point-of-sale terminals stay in the stores, and some vendor systems will stay in the old room until their contracts end. Ravi Menon's analytics team also has a marketing data feed that lives in another provider's cloud, which makes Birchline multicloud in a small way already. Lesson 8 looks at why organizations choose hybrid and multicloud on purpose and at the Google Cloud products that help manage them.

Networking terms for digital leaders

Cloud conversations soon turn to networks, and the exam guide expects a few basic terms. An IP address is the number that identifies a device or service on a network, much like a street address. The Domain Name System (DNS) translates names such as shop.birchline.example into IP addresses, so customers never have to remember numbers. Bandwidth is how much data a connection can carry in a given time, and latency is how long data takes to travel from one point to another. A connection can have plenty of bandwidth and still feel slow if latency is high, which is why the physical distance between users and servers matters.

Google Cloud organizes its infrastructure into regions, which are independent geographic areas such as us-east5 in Columbus, Ohio, and zones, which are separate deployment areas within a region with their own power and networking. Running an application across several zones protects it from a failure in one. Edge locations are points where Google's network connects to internet providers and where content can be cached close to users, so that a shopper in a small town still sees product photos quickly. Google connects all of these with its own private global fiber network, so traffic between regions does not have to cross the public internet.

# Rough round-trip delay from distance alone. Light in fibre covers about
# 200 km per millisecond; real networks add routing and processing delays.
speed_km_per_ms = 200
for place, km in [("same city", 30), ("nearby region", 550), ("across the continent", 4000)]:
    one_way = km / speed_km_per_ms
    print(f"{place:22} {km:5} km  minimum round trip about {2 * one_way:4.1f} ms")

same city                 30 km  minimum round trip about  0.3 ms
nearby region            550 km  minimum round trip about  5.5 ms
across the continent    4000 km  minimum round trip about 40.0 ms

The numbers explain why Birchline chose a region close to most of its customers and stores for the online shop, and why Farah wants the product photo library served through Google's edge locations rather than from a single region. A few milliseconds per request add up when a product page loads dozens of images.

The shared responsibility model

Moving to the cloud does not move all responsibility to the provider. Under the shared responsibility model, the provider is responsible for the security and operation of the cloud: the data centers, hardware, global network and the services it runs. The customer is responsible for security in the cloud: its data, who has access to it, how its resources are configured and, depending on the service model, its operating systems and applications. The dividing line moves with the service model. With IaaS, the customer patches the operating system; with PaaS, Google does; with SaaS, the customer mostly manages users and data.

Some responsibilities never move. The customer always decides who can access its data, always classifies and protects its own information, and always remains accountable to its customers and regulators. If an employee shares a storage bucket publicly by mistake, that is a customer configuration error, not a provider failure, even though the provider's systems stored the data perfectly. Teresa Okonjo, Birchline's information security manager, put it bluntly at the committee: "Google will run the building. We still have to lock our own doors." Google describes its own side of the arrangement as shared fate, meaning it also provides secure defaults, guidance and tools to help customers get their side right; lesson 9 returns to this.

Questions to ask before choosing a model

Farah gave Owen a short checklist to use whenever a team proposes moving a system. First, does the system give Birchline a competitive advantage, or is it a standard business function that many companies share? Standard functions lean toward SaaS. Second, can the code be changed? If the vendor or the age of the system makes changes impractical, IaaS may be the only realistic first step. Third, does the team have the skills to run servers well, and does it want to spend its time that way? If not, PaaS or serverless frees people for more valuable work. Fourth, what do contracts, licenses and regulations require about where data lives and who can see it? Fifth, how will the system be supported at three in the morning when something fails?

The answers often point to different models for different parts of one system. The online shop's web front end and order API suit serverless containers, its database suits a managed database service, and its payment processing is handled by a specialist payment provider as a service, which keeps most card data out of Birchline's own systems altogether. Mixing models like this is normal. What matters is that every part has a clear owner and that everyone knows which side of the shared responsibility line each task falls on.