Cloud Computing Models and Shared Responsibility

Study guide for Cloud Digital Leader, Unit 1 · Topic 3. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks. Discuss the benefits and tradeoffs of using infrastructure as a service (IaaS); platform as a service (PaaS); and software as a service (SaaS).

Objectives, quoted from the exam guide:

1. Define IaaS, PaaS, and SaaS.
2. Compare and contrast the benefits and tradeoffs of IaaS, PaaS, and SaaS including total cost of ownership (TCO), flexibility, shared responsibilities, management level, and necessary staffing and technical expertise.
3. Determine which computing model (IaaS, PaaS, SaaS) applies to various business scenarios and use cases.
4. Describe the cloud shared responsibility model. Compare which responsibilities are the cloud provider’s, and which responsibilities are the customer’s for on-premises and cloud computing models (IaaS, PaaS, SaaS).

Cloud computing models and shared responsibility

Three models, one question: how much do you still manage?

What each model is — infrastructure, platform or software as a service. What each costs you in control, customization, staff and total cost. Which one a scenario calls for. Who secures what — and the two things that never change hands.

This topic's summary in the guide is to discuss the benefits and trade-offs of infrastructure as a service, platform as a service and software as a service — IaaS, PaaS and SaaS. Google gives the one idea that holds all four objectives together: every one of these terms refers to how you use the cloud and the degree of management you are responsible for. So read the topic as a single dial. At one end you manage almost everything and control almost everything; at the other the provider manages almost everything and you control very little. The objectives ask you to define the three settings on that dial, weigh what each one costs you, choose one for a scenario, and — because security follows management — say who is responsible for what at each setting. One thing to hold from the start: the dial does not reach zero at either end. There are responsibilities that never leave the customer, and we will draw them.

Infrastructure, platform and software as a service

What the provider delivers, and what you still bring

Worked example (synthetic). A team says it "runs on PaaS" but patches the operating system on its own virtual machines every month. Whatever it calls itself, it is on IaaS: patching the operating system is the IaaS customer's job.

Google names three main cloud service models, and each is defined by what the provider delivers. Infrastructure as a service, or IaaS, delivers on-demand infrastructure resources — compute, storage, networking and virtualization. Customers no longer manage their own data center infrastructure, but they are responsible for the operating system, middleware, virtual machines, and any apps or data. Compute Engine and Cloud Storage are Google's examples. Platform as a service, or PaaS, delivers and manages all the hardware and software resources to develop applications. Customers still write the code and manage their data and applications, but the environment to build and deploy them is managed by the provider; Cloud Run and App Engine are the examples. Software as a service, or SaaS, provides the entire application stack — a complete cloud-based application, completely managed by the provider, including all updates, bug fixes and maintenance. Google Workspace is the example. And the phrase as a service itself has a meaning Google spells out: the service model is offered by a third party in the cloud. Read the third column top to bottom and the pattern is the whole objective: what you manage shrinks from an operating system, to your code, to your data.

Build a house, hire a builder, rent it furnished, move in

Google's own housing analogy, one step per model

Figure. Four cards following Google's housing analogy: on-premises is building the house yourself; IaaS is hiring a contractor, so you rent the hardware but manage the operating system, runtime, scale and data; PaaS is renting a furnished house, so you bring only your code; SaaS is moving into a finished house, so you look after only your data. A note places containers as a service between IaaS and PaaS.

Worked example (synthetic). Asked which model leaves a team responsible only for its own data, the graded answer is SaaS — the finished house — even though the team still pays for upkeep.

Google teaches these models with a housing analogy, and it is worth borrowing because each step removes one kind of work. On-premises is building the house from scratch: you own everything from the hardware to your applications and scaling. Infrastructure as a service, or IaaS, is hiring a contractor: you rent the hardware to run your application on, but you are responsible for managing the operating system, runtime, scale and all the data. Platform as a service, or PaaS, is renting a furnished house: you bring your own code and deploy it, and the server management and scaling are left to the cloud provider. Software as a service, or SaaS, is moving into a finished house: you pay to use a complete application that is managed, maintained and secured by the provider, and you remain responsible for taking care of your own data. Google also slots in containers as a service, or CaaS, between the first two settings: with containers you bring a containerized application, so you do not worry about the underlying operating system but still control scale and runtime. The exam names three models; knowing where CaaS sits simply stops Google Kubernetes Engine looking like a fourth.

What each model costs you, and buys you

Control and customization trade against management and staffing

• IaaS: the most control over infrastructure, and hands-on maintenance
• PaaS: provider maintains and secures the infrastructure; less control
• SaaS: provider manages everything; little to no customization
• TCO: managed services cut operational overhead that VMs quietly add

Worked example (synthetic). Two teams host the same web app. One runs it on virtual machines and spends a day a week patching; the other runs it on a managed platform and spends that day on features. The second team's hourly price may be higher and its total cost lower.

The second objective asks you to compare the three models on five dimensions: total cost of ownership, flexibility, shared responsibility, management level, and the staffing and expertise each one needs. Google's framing is that the difference comes down to the level of control and responsibility, and that the provider manages different elements of the computing stack depending on which model you choose. On flexibility and control, infrastructure as a service, or IaaS, gives the highest level of control over infrastructure — and in exchange requires hands-on configuration and maintenance, which is a staffing statement: someone skilled has to do it. Platform as a service, or PaaS, moves maintenance and securing of infrastructure to the provider, at the cost of less control over operations and more limited customization. Software as a service, or SaaS, has the provider manage and maintain everything from hardware to software, and offers little to no customization. On total cost of ownership, or TCO, Google's cost framework is explicit that the cheapest-looking option is not the cheapest one: virtual machines might look cost-effective, but when you consider the overhead to maintain, patch and scale them, the TCO can increase. Its advice is to choose managed services and serverless products whenever possible to reduce operational overhead and maintenance costs — the lower overhead lets your team focus on core activities, and serverless services like Cloud Run can offer greater business value. One cost runs the other way: for PaaS and SaaS, Google lists vendor lock-in as a possible issue.

The five dimensions, side by side

Read across a row to see one trade-off move

Worked example (synthetic). A hospital has no developers and needs scheduling software next quarter. Read the staffing row: SaaS is the only column that does not assume expertise the hospital lacks.

Here are the five dimensions as a grid, and the reason to draw it is that each row moves in the same direction. Control and flexibility fall from left to right: IaaS has the highest level of control over infrastructure, PaaS less control over operations, and SaaS no control over any of the infrastructure or security controls. Customization falls with it, to little or none for SaaS. Management level falls the other way for you and rises for the provider: IaaS requires hands-on configuration and maintenance, with PaaS the provider is responsible for maintenance and securing infrastructure, and with SaaS the provider manages and maintains everything. Staffing follows management, and so does security work: Google lists being responsible for your own data security and recovery as an IaaS disadvantage. Google's shared-responsibility page makes the SaaS end concrete: you use SaaS when your enterprise does not have the internal expertise or business requirement to build the application itself. And the total-cost row is where people go wrong. One of the primary reasons businesses choose IaaS is to turn capital expenditure into operational expense, but each step right also removes operational overhead, which Google's framework counts in total cost of ownership. The columns are infrastructure as a service, platform as a service and software as a service, and TCO is total cost of ownership.

Which model does the scenario call for

Look for what the organization wants to stop doing

• Lift-and-shift, or specific VMs, databases and network configs: IaaS
• Building an app and focusing on development, not infrastructure: PaaS
• No internal expertise to build it, but the work must get done: SaaS
• Most estates are a mix — the models are not mutually exclusive

Worked example (synthetic). A retailer moves its warehouse system to Compute Engine unchanged, builds a new storefront on Cloud Run, and runs email on Google Workspace. That is one company on all three models at once — and nothing about it is unusual.

The third objective turns the definitions into a choice, and Google's shared-responsibility page states the three triggers almost word for word. You use infrastructure as a service, or IaaS, if you plan on migrating an existing on-premises workload to the cloud using lift-and-shift, or if you want to run your application on particular virtual machines, using specific databases or network configurations. You use platform as a service, or PaaS, if you are building an application such as a website and want to focus on development, not on the underlying infrastructure. And you use software as a service, or SaaS, when your enterprise does not have the internal expertise or business requirement to build the application itself, but does need the work done. A useful habit is to read a scenario for what the organization wants to stop doing: stop running a data center but keep the configuration — IaaS; stop managing servers — PaaS; stop building software — SaaS. The last point on the slide is the one the exam uses as a trap. Google says the three are not mutually exclusive: you can combine one with another, or use a mix of all three along with more traditional information technology (IT) infrastructure. An answer that forces a single model on a varied estate is usually wrong.

Three questions that pick the model

Ask them in order; the first yes decides

Figure: A decision flow of three questions asked in order. If the organization needs a finished application and has no expertise to build one, choose SaaS, such as Google Workspace. Otherwise, if it is writing the application and wants to focus on the code, choose PaaS, such as Cloud Run or App Engine. Otherwise, if it is moving an existing workload as it is or needs specific virtual machines and configurations, choose IaaS, such as Compute Engine.

Worked example (synthetic). An item describes a firm that wants to rehost a licensed application on the exact operating system it runs today. The first two answers are no, the third is yes: IaaS.

Drawn as a decision, the third objective becomes three questions asked in order, from the most managed model to the least. First: does the organization need a finished application and lack the expertise to build one? Then it is software as a service, or SaaS, and Google Workspace is the example. If not: is it writing the application itself and wanting to focus on the code rather than the infrastructure? Then platform as a service, or PaaS — Cloud Run or App Engine. If not: is it moving an existing workload unchanged, or does it need particular virtual machines, databases or network configurations? Then infrastructure as a service, or IaaS, and Compute Engine. The order matters because it matches Google's advice elsewhere to prefer managed services whenever possible: you only fall through to the model where you manage the most when the more managed ones cannot do the job.

The shared responsibility model

Two things never change hands, whichever model you pick

Figure. Two stacked zones. Above, always the customer's under every model: your data and access policies. Below, always Google Cloud's once the workload runs on it: the underlying infrastructure, the underlying network and physical security. A callout notes that everything between the two moves with the model chosen.

Worked example (synthetic). A company moves its email to a SaaS product and assumes security is now entirely the provider's. It still owns who has access and what data goes in — those two are the customer's under every model.

The fourth objective is the shared responsibility model, which Google defines as describing the tasks you have when it comes to security in the cloud, and how those tasks differ from the cloud provider's. Before comparing models, fix the two things that never move, because every question on this objective leans on them. Google's page says it directly: the cloud provider always remains responsible for the underlying network and infrastructure, and customers always remain responsible for their access policies and data. That is what the figure draws. Underneath, under every model, is Google Cloud's: the infrastructure, the network, and — Google's own words for the infrastructure-as-a-service case — physical security. On top, under every model including software as a service, is yours: your data and who can access it. The callout is the rest of the objective. Everything between those two lines moves as you choose a more or less managed model, and the next slide follows it.

Where the line sits, model by model

On-premises you hold everything; each step hands some over

Worked example (synthetic). An item asks who patches the operating system of a Compute Engine virtual machine. The IaaS row answers it: the operating system is the customer's.

Now follow the line as it moves. On-premises there is no provider in the picture: you own everything from the hardware to your applications and scaling. In infrastructure as a service, or IaaS, Google says the bulk of the security responsibilities are yours, and its own are focused on the underlying infrastructure and physical security; its IaaS page lists what you secure as your data, applications, virtual network controls, operating system and user access. In platform as a service, or PaaS, Google is responsible for more controls than in IaaS, and you share responsibility for application-level controls and identity and access management (IAM); you remain responsible for your data security and client protection. In software as a service, or SaaS, Google owns the bulk of the security responsibilities, and you remain responsible for your access controls and the data you choose to store in the application. Functions — function as a service, or FaaS — sit with SaaS: Google says FaaS has a similar shared responsibility list. Read the customer column bottom to top and it never empties; it only shrinks to the two things on the previous slide.

Shared responsibility, and Google's shared fate

A division of tasks, and a partnership on top of it

Figure. Two cards. Shared responsibility divides security tasks between provider and customer, and is hard to apply because many breaches come from misconfiguration and most estates mix several service types. Shared fate, Google's extension, treats the relationship as an ongoing partnership to improve security, starting with a trusted cloud platform.

Worked example (synthetic). A bank on IaaS, PaaS and SaaS at once finds three different responsibility lists. Shared responsibility tells it which list applies where; shared fate is Google's commitment to help it configure each one well.

Google adds one idea on top of the model, and it is worth knowing by name. The shared responsibility model is a division of tasks, and Google is candid that applying it is hard. Many cloud security breaches, it says, are the direct result of misconfiguration, and though dividing items by cloud service is helpful, many enterprises have workloads that require multiple cloud service types — so a single company is reading several responsibility lists at once. Google's answer is what it calls shared fate. Shared fate builds on the shared responsibility model because it views the relationship between cloud provider and customer as an ongoing partnership to improve security, and it includes Google building and operating a trusted cloud platform for your workloads. Shared fate does not move the line on the previous two slides — your data and access policies are still yours. It changes how much help you get on your side of it.

What this topic actually tests

One dial, and the two ends it never reaches

What do you still manage? operating system (IaaS), code (PaaS), data (SaaS). What does the scenario want to stop doing? that picks the model — and mixing models is normal. Who secures what? the line moves with the model; your data and access policies never leave you, and the infrastructure never leaves Google.

Close on the three habits this topic rewards. First, when a model is named, ask what the customer still manages: the operating system and everything above it under infrastructure as a service, the code and data under platform as a service, and the data alone under software as a service. Second, when a scenario is described, ask what the organization wants to stop doing — running hardware, managing servers, or building software — and remember that most real estates use more than one model at once. Third, when security is in the question, remember the line moves with the model but has two fixed ends: the provider always remains responsible for the underlying network and infrastructure, and customers always remain responsible for their access policies and data. Unit 5 returns to that line in far more detail; this topic is where it is first drawn.

Official sources for this topic

• Cloud Digital Leader exam guide — Section 1
• PaaS vs. IaaS vs. SaaS vs. CaaS — Google Cloud
• What is IaaS? — Google Cloud
• Well-Architected Framework — Align cloud spending with business value
• Shared responsibilities and shared fate on Google Cloud