Containers in the cloud

Study guide for Cloud Digital Leader, Unit 4 · Topic 4. 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 advantages of using containers in application modernization.

Objectives, quoted from the exam guide:

1. Discuss the advantages of modern cloud application development.
2. Differentiate between virtual machines and containers.
3. Discuss the main benefits of containers and microservices for application modernization.
4. Discuss the business value of using Google Cloud products to deploy containers, including: Google Kubernetes Engine (GKE); Cloud Run.

Containers in the cloud

Why modernization so often means containers

How software is built now — loosely coupled, released continuously. What a container is not — a smaller virtual machine. What containers and microservices buy a modernization, and what they cost. Where to run them — GKE or Cloud Run, and who manages what in each.

The guide's summary for this topic is to discuss the advantages of using containers in application modernization. Topic two already defined a container and set it beside a virtual machine; this topic asks why that difference matters to a business that is changing how it builds software. Its four objectives run in a line. First, what modern cloud application development is and why it is faster. Second, the difference between virtual machines and containers — this time looking at the two stacks rather than the two definitions. Third, what containers and microservices do for an application being modernized, and what they cost. And fourth, the business value of the two Google Cloud products that run containers: Google Kubernetes Engine, GKE, and Cloud Run. The thread through all four is a single idea from Google's cloud-native page: cloud native refers to how applications are built and delivered, rather than just where they are deployed.

What modern cloud application development changes

Smaller pieces, released continuously, by one team

• Loosely coupled services instead of one unit built, tested and deployed together
• Deploy and scale components independently, without service interruption
• DevOps: developers and IT operations automate delivery together
• Continuous integration and delivery: release without a maintenance window

Worked example (synthetic). A retailer's checkout, catalog and search ship as one release every quarter, after a weekend outage. Split and automated, the search team ships a fix on Tuesday afternoon while checkout keeps taking orders.

The first objective asks for the advantages of modern cloud application development, and Google states the contrast with one sentence. Unlike monolithic applications, which must be built, tested and deployed as a single unit, cloud-native architectures decompose components into loosely coupled services — to help manage complexity and improve the speed, agility and scale of software delivery. The problem with the single unit is named just as plainly: it creates close dependencies, making it more difficult to change, test, deploy and operate systems as they grow over time. What the modern approach buys is the ability to deploy and scale components independently, so teams can make updates, fix issues and deliver new features without any service interruption. Two practices make that routine rather than heroic. DevOps, in which developers and information technology (IT) operations teams collaborate to automate infrastructure and software delivery. And continuous integration and continuous delivery, CI/CD, whose pipelines automate the build, testing and deployment of changes without the need to schedule downtime or wait for a maintenance window. The business outcome Google names is simple: products reach market faster, and each deployment carries less risk — because cloud-native applications make the most of modern infrastructure's dynamic, distributed nature to achieve greater speed, agility, scalability, reliability and cost efficiency.

The same four questions, answered two ways

What changes when an application is built cloud native

Worked example (synthetic). A bank's mobile app team waits six weeks for a release slot shared with forty other changes. Moving to a pipeline, the question it stops asking is "when is the next window?"

Set side by side, the advantages of modern development are answers to four questions a business already asks. How is the software shipped? The monolith is built, tested and deployed as a single unit; a cloud-native application is loosely coupled services, each deployed on its own. When can it change? Traditionally, in a maintenance window; with continuous integration and continuous delivery (CI/CD), Google says changes deploy without the need to schedule downtime or wait for that window. Who runs a release? DevOps puts developers and information technology (IT) operations in the same effort, automating delivery together. And what causes downtime? Google credits cloud-native architectures with infrastructure automation that helps eliminate downtime due to human error. Every row is the same trade: work that used to be scheduled and manual becomes automatic and continuous.

Two stacks, side by side

A VM carries a whole operating system; a container shares one

Figure. Two stacks side by side. The virtual machine stack holds the application and libraries, a guest operating system of its own, virtualized hardware and the host. The container stack holds the application and libraries, no operating system of its own, the host operating system kernel shared between containers, and the host.

Worked example (synthetic). A team runs twelve small services, each in its own virtual machine, and pays for twelve operating systems it never touches. The same services as containers share one host kernel.

The second objective is the difference between virtual machines and containers, and the fastest way to hold it is to draw both stacks. Google begins with what they share: both are used to isolate applications, and like virtual machines, containers package an application together with its libraries and other dependencies. Then the stacks part. In a virtual machine, a guest operating system such as Linux or Windows runs on top of a host operating system with access to the underlying hardware — Google's phrase is that a virtual machine virtualizes the entire physical hardware stack, including the operating system. Every virtual machine carries its own. A container virtualizes only the operating system layer: instead of bundling a full operating system with each application, it shares the host's operating system kernel. That one missing layer is where every other difference comes from.

What the missing layer changes

Size, start-up and where it can run

Worked example (synthetic). An exam item offers "containers are smaller virtual machines". The graded answer rejects it: the difference is not size but which layer is virtualized, and size follows from that.

Everything in this table follows from the layer each one virtualizes. Google's summary is that containers virtualize at the operating system level while virtual machines virtualize at the hardware level. Because each virtual machine is a self-contained, isolated environment with its own operating system, virtual machines tend to be larger and take up more resources. Because containers share the operating system kernel, Google says they use a fraction of the memory virtual machines require — and the virtual machine page adds that containers use fewer resources and start up faster while remaining isolated. The last row is portability: containers can run virtually anywhere — on Linux, Windows and Mac operating systems, on virtual machines or physical servers, on a developer's machine, on-premises, or in the public cloud. Notice that a container can run on a virtual machine; they are not rivals at the same layer. When an item describes containers as small virtual machines, it has the layers wrong.

Containers and microservices in a modernization

Smaller independent parts, each packaged the same way

• Microservices: a large application split into independent parts
• Scale each service on its own; one failure need not stop the rest
• Containers: isolation, portability and scale for each service
• Cost: tracing one request across many services is complex

Worked example (synthetic). An insurer's quote engine and claims portal share one codebase, so a claims bug blocks new quotes. Split into services, a claims failure leaves quoting untouched — and the team now needs tracing to find which service failed.

The third objective asks for the main benefits of containers and microservices for application modernization, and they are two halves of one move. Microservices change the shape of the application: Google says they allow a large application to be separated into smaller independent parts, each with its own realm of responsibility, and each self-contained, with its own code, data and dependencies — where a traditional monolithic application is built as a single, unified unit. Google says microservices are typically used to speed up application development, and two further benefits follow directly. Individual microservices can be scaled independently based on their specific needs. And if one microservice fails, it does not necessarily impact the entire application. Containers change how each part is packaged and run: Google calls them a natural fit for microservices, providing isolation, portability and scalability for individual services, and a clear separation of responsibility — developers own application logic and dependencies, operations own deployment and management. Be honest about the price. Google's own microservices page says tracking a single request across dozens of independent services is complex, which is why observability becomes critical. The benefit is real; so is the new work.

Three ways containers enter a modernization

Wrap it, split it, or build the pipeline around it

Figure: A flow from an existing application on a virtual machine, to wrapping it in a container without the guest operating system layers, to splitting it into independent microservices, to shipping it through consistent CI/CD pipelines. A dotted arrow from the wrapping step shows that value arrives before the application is ever split.

Worked example (synthetic). A manufacturer cannot justify rewriting its scheduling system. It wraps the existing application in a container first, gains portability, and splits off services only where scaling pressure appears.

Modernization with containers is not a single jump, and the figure shows the three places it can start. The first is wrapping. Google says containers can help modernize existing applications by encapsulating them in a portable and scalable format, and its application modernization offering describes an automated approach that extracts critical application elements from a virtual machine and inserts them into containers in Google Kubernetes Engine (GKE), without the virtual machine layers — like the guest operating system — that become unnecessary with containers. Value arrives at this step already, before a line of the application is rewritten. The second is splitting into microservices, which buys independent scaling and failure isolation. The third is the pipeline: Google says containers may be used to create consistent and reproducible continuous integration and continuous delivery (CI/CD) pipelines, so applications are built, tested and deployed reliably. An exam item that assumes modernization must begin with a rewrite has skipped the first step.

The business value of GKE and Cloud Run

Two ways to run containers, priced in operations

• GKE: managed Kubernetes, built on Google's experience running Borg
• Autopilot: Google runs control plane and nodes; pay for what Pods request
• Cloud Run: no cluster; developers spend their time writing code
• Gradual rollouts and idle containers removed as demand falls

Worked example (synthetic). A logistics firm runs a stateful routing engine with custom hardware needs, and a dozen small web APIs. The engine belongs on GKE; the APIs on Cloud Run — from the same container images.

The fourth objective asks for the business value of the two Google Cloud products that run containers. Google Kubernetes Engine, GKE, is a managed implementation of the Kubernetes open source container orchestration platform — and Kubernetes itself was developed by Google, drawing on years of experience operating production workloads at scale on Borg, Google's in-house cluster manager. GKE's value is control with less toil. It is ideal if you need to configure the infrastructure that runs your containerized apps — networking, scaling, hardware and security — and it offers a managed upgrade experience with release channels to improve security, reliability and compliance. Its Autopilot mode goes further: Google manages your nodes, scaling, security and other preconfigured settings, and you pay only for the compute resources your running Pods request, where Standard mode bills every resource on the nodes regardless of what Pods request. Google calls Autopilot clusters the recommended way to use GKE. Cloud Run's value is time. It is a fully managed application platform for running code, a function or a container — code in any programming language, if you can build a container image from it; you do not have to create a cluster or manage infrastructure; and Google sums it up as developers spending their time writing code and very little time operating, configuring and scaling. It removes idle containers when demand decreases, and supports gradual rollouts that reduce the risk of deploying a new revision.

Who manages what in GKE

In Autopilot, Google's line sits above the nodes

Figure. Two stacked zones. The upper zone, yours in every GKE mode, holds container images and Kubernetes manifests. The lower zone, Google's in Autopilot mode, holds the control plane, the nodes, and scaling and security settings. The callout notes that in Standard mode the nodes move up to the customer while the control plane stays Google's.

Worked example (synthetic). A team with no one to patch nodes compares GKE modes. The figure answers it directly: in Autopilot there are no nodes on their side of the line.

A Google Kubernetes Engine (GKE) cluster, in Google's words, consists of a control plane and worker machines called nodes. The business question is who manages each, and the answer depends on the mode. In Autopilot, GKE manages the entire underlying infrastructure of the cluster, including the control plane, the nodes and all system components; what remains on your side is what you build and declare — the container images, and the Kubernetes manifests from which, Google says, Autopilot provisions compute resources. In Standard mode the line moves: GKE manages the control plane and system components, and you manage the nodes. Notice what does not move. The control plane is Google's in both modes, which is why even Standard is a managed service. The choice between modes is really a choice about who does node operations — and that is the staff time a business is paying for.

GKE or Cloud Run — and why it need not be either

Same container image, two operating models

Worked example (synthetic). A media company launches its recommendation API on Cloud Run for speed, then needs custom hardware as it grows. It moves the same image to GKE — no rebuild, no rewrite.

The last figure sets the two products side by side and then removes the either-or. Google Kubernetes Engine (GKE) supports both stateless and stateful applications and is ideal for complex applications with specific resource needs. Cloud Run is best suited for stateless, request- or event-driven services, web services and functions, and Google's one-line summary of it is ideal for simplicity and speed. On most business questions, then, the choice follows from the workload. But Google is explicit that you do not need to choose between the two platforms: you can use the same image for your application in either platform without any modifications, enabling seamless migration of workloads between GKE and Cloud Run. The same portability runs further than Google Cloud. GKE groups clusters into a fleet, and Google says a fleet can be entirely made up of GKE clusters on Google Cloud, or include clusters outside it. That is the business value of standardizing on containers: the decision about where to run is reversible.

What this topic actually tests

Four discriminations, four objectives

Where it runs, or how it is built? cloud native is the second. Which layer is virtualized? hardware for a VM, the OS for a container. What does splitting buy, and cost? independent scale and failure — and harder tracing. Who manages the nodes? Google in Autopilot, you in Standard, nobody you see in Cloud Run.

Close on the four discriminations this topic turns on. First, modern development is about how applications are built and delivered, not only where they are deployed — loosely coupled services, released continuously through automated pipelines. Second, a virtual machine and a container differ in the layer they virtualize: the virtual machine carries a whole operating system, the container shares the host's kernel, and size, start-up time and portability all follow from that. Third, microservices buy independent scaling and failure isolation, containers make each service portable and consistent — and the cost is that tracing one request across many services becomes hard. Fourth, the Google Cloud products differ in who manages what: in Google Kubernetes Engine (GKE) Autopilot, Google runs the control plane and the nodes; in Standard, you run the nodes; in Cloud Run there is no cluster to run at all. And because the same container image runs on either, the choice can be changed later.

Official sources for this topic

• Cloud Digital Leader exam guide — Section 4
• What is cloud native? — Google Cloud
• What is a virtual machine? — Google Cloud
• What are containers? — Google Cloud
• What is microservices architecture? — Google Cloud
• GKE overview
• GKE Autopilot overview
• What is Cloud Run
• Application modernization — Google Cloud
• GKE cluster architecture
• GKE and Cloud Run
• Fleet management overview — GKE