Web & Cloud

This is Unit Ten of Computer Science: the web, and the cloud. The web started as one move — a way to link content stored on different machines. Everything since is elaboration on that, and the exchange underneath every page you have ever loaded is still a request going out and a response coming back. The unit divides into two halves. The first is the web itself, in three phases, ending with a phase that removes the central server the first two assumed. The second half is the cloud, and the organising idea there is a question about what somebody else operates on your behalf. Three service models answer it at three different levels, and the full span runs from owning physical machines to owning nothing that persists at all. There is also a distinction the unit is careful about — between an application that runs in the cloud and one built to use what the cloud actually offers. Those are not the same thing and the difference is not marketing. By the end you will be able to do five things. One: say what a request and response exchange, and what encryption adds. Two: say what changed across the web's three phases. Three: say what a container isolates and what orchestration adds. Four: name the three service models and what each hands over. Five: say what separates cloud-based from cloud-native.

Three entries. What the web was invented to do, the exchange that has sat underneath it ever since, and the layer added later — which is the difference between sending something across a network and sending it privately.

The founding move.

CS 0541 The Web's Founding Move

A way to link content stored on different machines. One idea — that a document here could point at a document there — and the rest of the unit follows from it.

The exchange.

CS 0542 Request and Response

A browser transmits a request to a server running at a located address, and the server sends a response back. Every page load anybody has ever performed is this.

Adding privacy.

CS 0543 HTTPS

An encryption layer added to the transfer protocol, protecting sensitive information in transit. The exchange is unchanged — what changed is who else can read it.

Five entries. Three phases of what the web could do, and then the three shapes an application on a phone can take — each trading reach against performance in a different way.

The first two phases.

CS 0544 Web 1.0, Then 2.0

The first phase left users mostly reading and selecting pages. The second added interactivity — which is what turned a document system into an application platform.

How that worked.

CS 0545 AJAX

Exchanging small amounts of data between client and server, so a page could change without being fetched again from the start. A small technical change with a large consequence.

What it enabled.

CS 0546 The Single-Page Application

Functionality resembling a traditional desktop program, with small transmissions replacing whole page loads. The browser stopped being a viewer.

The third phase.

CS 0547 Web 3.0 and the Distributed Ledger

Applications running without a centralised server, executing programs held on a distributed ledger. It removes the one thing the first two phases took for granted — that somebody is running the server.

Three shapes.

CS 0549 Native, Web, Hybrid

Native applications target one operating system and reach the hardware at full performance; web and hybrid forms trade some of that for reach. Three shapes, one application.

One procedure, and it is the demonstration this unit needed. A single tap on a modern application, followed all the way out and all the way back — request, response, encryption, render.

Watch one tap travel.

CS 0570 One Tap, Round Trip

A single interaction running the unit's whole communication stack. Nothing about it is unusual, and that is the point — the ordinary case is what the whole stack was built for.

Five entries. What the cloud is, four principles built on it, the unit that software gets packaged into, and then a distinction the unit is precise about — between running somewhere and being built for it.

What it is.

CS 0552 The Cloud

Data, software and services running on the Internet rather than on a local machine, with capacity available on demand. Somebody else's computers, arranged so that matters less than it sounds.

Four principles.

CS 0553 Cloud-Native's Four Principles

Microservices, containerisation, continuous delivery and the operations methodology from Unit Nine. Two of the four are practices this course already taught elsewhere.

The package.

CS 0554 The Container

A standardised unit of software logically isolating an application so it runs independently of what is around it. Isolation from Unit Six, applied to deployment rather than to execution.

Managing many.

CS 0555 Container Orchestration

Scaling, managing and automating the deployment of containerised applications. Once containers are the unit, something has to schedule them — which is Unit Six's problem again at a larger size.

And the distinction.

CS 0556 Cloud-Based or Cloud-Native

A cloud-based application runs in the cloud. A cloud-native one is built to use the cloud's actual traits — resources appearing and disappearing on demand. The first is a location. The second is a design.

Five entries organised by one question: how much does somebody else operate. The three models answer it at three levels, and the last entry stretches the same axis out to both ends.

Three levels.

CS 0559 The Three Service Models

Infrastructure, platform, and software as a service — each handing more of the operating burden to the provider. One axis, three points on it.

The first.

CS 0560 Infrastructure as a Service

On-demand access to hosted infrastructure — servers, storage, network. You still operate everything above the hardware.

The second.

CS 0561 Platform as a Service

On-demand access to a hosted platform for developing, running and managing applications. The operating system and its upkeep stop being your concern.

The third.

CS 0562 Software as a Service

Hosted, ready-to-use software reached through a client. Nothing about how it runs is yours, and nothing about how it runs is your problem.

Both ends of the axis.

CS 0563 Bare Metal to Serverless

Deployment technologies span from dedicated physical servers you provision and maintain, all the way to arrangements where nothing persists between requests. The three models are points along a longer line.

Three entries on ownership. Who a cloud belongs to and who may use it, and then the two arrangements built by mixing — one keeping sensitive material in-house, one refusing to depend on a single provider.

Four ways.

CS 0564 The Four Deployment Models

Private to one organisation, community across several with shared concerns, public for general use, and hybrid combining them. Ownership, not technology.

Keeping some local.

CS 0565 The Hybrid Cloud

Combining cloud and on-premises resources, with sensitive data kept local under fuller management rights. The split is decided by what the data is, not by what is cheaper.

More than one provider.

CS 0566 The Multicloud

More than one public or private cloud meshed into a single environment. The reason is usually independence rather than capability.

Two entries closing the unit. One is a pointer — the frontier material about intelligent networked systems belongs to a different course, and the entry says so rather than half-teaching it. Then the capstone.

A pointer.

CS 0568 Intelligence, Pointed Home

The cloud's frontier material describes intelligent autonomous networked systems, and that content belongs to its own course. Naming the boundary is better than crossing it badly.

The capstone. The app, to production.

CS 0575 The App Ascends

The transit app built in Unit Nine goes to production in this unit's territory — served over the web, packaged into containers, deployed onto somebody else's infrastructure.

Five things you can now do. You can say what a request and response exchange — a browser asking a server at a located address, and the server answering — and that encryption changes who else can read it rather than changing the exchange. You can say what changed across the web's three phases: reading, then interacting, then running without a central server at all. You can say what a container isolates — an application, from whatever surrounds it — and that orchestration schedules many of them. You can name the three service models and what each hands over, from infrastructure you still operate on top of, to software that is nothing but ready to use. And you can say what separates cloud-based from cloud-native: the first names a location, the second names a design.