Cloud Computing

“Wind of Dreams,” Pen on Paper, 11” x 14”

Created 02/09/2024, Study of Franklin Booth’s piece. See my Art Gallery.

On-demand, self-service

Why get cloud computing services? Because teams want to get servers fast and get servers now. They might not want to build and maintain physical servers; what if their base of operations is just a garage?

To earn money off of these developers, businesses called cloud providers assemble, configure, and maintain lots of servers. Like landlords (the analogy tells you this is a profitable trade), they share their servers with a lot of users.

In contrast with landlords, cloud providers provide easy access to their resources; there no paperwork associated, no barrier to entry. Cloud services typically have the following attributes:

• Rapid elasticity: clients can get new servers quickly.
• Multitenancy: multiple clients share the same hardware.
• Measured service: clients are billed according to the amount of computational resources they used.
• Broad network access: cloud servers are available from many locations.

Cloud Service Models

The following models are provided with increasing levels of abstraction.

“Infrastructure as a Service”:

service provider gives hardware only, user supplies OS, apps, etc.
Example: AWS, although nowadays they have lots of more abstracted services as well.

“Platform as a Service”:

The cloud provider supplies hardware with an installed OS and basic, free tools (like Python and vim).
Example: Google App Engine, others.

“Software as a Service”:

The cloud provider supplies a pre-configured software stack. Clients don’t need to install things, instead, they make in-app requests.
Example: Salesforce, OneDrive, OSS storage, others.

Virtualization

Recall that cloud services make multiple users share the same hardware (to save costs). This operation model conflicts with how a regular OS is designed.

On a single machine, each user can see all running processes. This creates an “information leak” through which a client can see another clients’ business secrets.

Additionally, if client A’s process creates a fork bomb and chews up the entire CPU, every other client’s process will be impacted. Evidently, we want a harder boundary between clients.
Virtualization is a common technique in software design! If lots of users want processes, to keep things secure and compatible, we tell the software to pretend to be hardware.

For example, we can write a big C program to emulate a CPU that uses the ARM instruction set. The client’s software is run through this emulator. To the client program, all instructions return the correct results and they are the only process on this virtual machine! The other processes are safe and hidden.

To eliminate one misbehaving process from chewing up resources for all other processes, the CPU emulator also tells the client process it has less memory and storage than the machine actually does. This way, many CPU emulators can partition the physical storage.

As an additional advantage, we can also compile and run this C program on a X86 machine. Now, our emulator allows clients to run ARM code and our server is more flexible.

It appears that virtualization is very beneficial. However, it comes with a performance cost. According to Prof. Eggert, naively implementing virtual machines tanks performance by around 10x.

Getting Help from Hardware

IF simulated architecture = actual architecture
THEN most hardware provides support for virtual software
– innocuous instructions are run on hardware at full speed
– dangerous instructions are run by software (HALT, for example, doesn’t stop all processes, it uses software to stop all user processes)

BUT WE WANT FASTER: CONTAINERS

VMs specialized to have the same OS as the operating system on disk.

Docker

Docker provides tools to specify local environments for process execution and provides a quick way to copy these environment specs and recreate these environments on different machines.

container: environment to run apps, implemented as a Linux process
image: template to build containers
service: lets containers scale across multiple machines
registries: repositories for Docker images

“docker porcelain”

With the “plumbing” of docker installed, we would like some “porcelain” to make it prettier and easier to use. Some concepts and problems in this area include:

Kubernetes, AWS Elastic Container Service
load balancing
resource constraints
log/monitoring
security
updating (while people are using the system, yuck!)

“Serverless Computing”

This is a newer, trendier marketing term. It is Cloud-based computing where the user can write code without referring to any server architecture or setup. In this way it is quite like Python.
In reality, the infrastructure routes the application to a server preconfigured by the Cloud provider. This additional layer of abstraction results in simpler code but comes at the cost of an efficiency hit.