Cloud

The cloud is computing you rent instead of own: servers, storage and databases in someone else's data centre, switched on with an API call and paid for by the hour, the gigabyte or the request. It is how a small team can put an app in front of the whole internet without buying a single machine.

What the cloud actually is

Providers such as AWS, Microsoft Azure and Google Cloud run enormous data centres full of servers, disks and network equipment, and rent it out in pieces. When you ask for a virtual machine, software on their side finds spare capacity, carves out a slice of a physical server and hands it to you, usually within a minute or two. When you delete it, the billing stops.

Three things set this apart from renting a server the old way:

• On demand. You create and delete resources yourself, from a web console, a command-line tool or an API call. There is no purchase order and no wait for hardware to arrive.
• Elastic. You can go from one server to fifty and back again in the same afternoon.
• Metered. You pay for what you use, much like electricity, instead of paying up front for capacity you might never need.

The old line 'the cloud is just other people's computers' is true, and worth remembering. Your data sits on physical disks in a real building, in a region you choose. What you are buying is someone else doing the hardware work, plus the services built on top of it.

Why not buy your own servers?

Running your own hardware means paying up front, guessing how much you will need, and dealing with power, cooling and failed disks yourself. Guess too small and the site falls over on launch day. Guess too big and expensive machines sit idle for years.

The cloud turns that up-front cost into a running cost, and shrinks the guess from 'how many servers will we need in three years?' to 'how many do we need right now?'. For a new app with unknown traffic, that is usually the deciding factor. Owning hardware still wins in some cases, which Cloud vs. on-prem looks at.

The main building blocks

Providers offer hundreds of services, but most apps use a handful. The names differ; the ideas are the same.

Compute

A virtual machine (Amazon EC2, Azure Virtual Machines, Google Compute Engine) is the closest thing to a server of your own. You choose the CPU, memory and operating system, and you are responsible for everything installed on it, including security updates. Managed app hosting sits a step higher: you hand over your code and the provider runs the machines.

Storage

Object storage (Amazon S3, Azure Blob Storage, Google Cloud Storage) keeps files as objects inside buckets. Azure calls a bucket a container. Each object has a key, which works like a file path, and you read and write it over HTTPS. It is cheap, very durable and has no practical size limit, so it is the default home for images, videos, backups and static websites.

It is not a disk you plug into a server: you can't edit the middle of a file in place, only upload a new version of the whole object.

Databases

A managed database gives you a working database without running the server it lives on. The provider installs it, patches it, takes backups and can keep a standby copy ready if the main one fails. You get a connection string.

• Relational (SQL) services such as Amazon RDS, Azure SQL Database and Cloud SQL suit data with relationships, where you need joins and transactions: orders and customers, users and their posts.
• NoSQL services such as Amazon DynamoDB, Azure Cosmos DB and Firestore suit simple lookups by key at very large scale, or data whose shape changes often.

Functions

A serverless function (AWS Lambda, Azure Functions) is a small piece of code the provider runs for you when something happens: an HTTP request, a file landing in a bucket, a message on a queue, a timer. You don't create or manage a server at all. There are still servers, you just never see them, and you pay per call and for the time your code runs.

Functions suit short, event-driven jobs. Each run has a maximum duration, you can't rely on memory surviving between calls, and a function that hasn't run for a while starts more slowly, which is called a cold start.

Who manages what

The more of the stack the provider runs, the less you have to look after, and the less you can customise. The three usual levels:

Whatever the level, security is shared. The provider secures the buildings, hardware and the service itself. You are responsible for who can reach your resources, how they are configured and what you store in them. Many cloud security incidents come from the customer's side of that line, such as a storage bucket accidentally left open to the public.

How scaling works

There are two ways to handle more traffic. Scaling up (vertical scaling) means moving to a bigger machine with more CPU and memory. Scaling out (horizontal scaling) means adding more machines of the same size and spreading requests between them with a load balancer. Scaling up has a ceiling; scaling out can keep going.

Cloud providers automate scaling out. You set a minimum and maximum number of servers and a rule, such as 'keep average CPU around 60%'. When traffic rises past the rule, the platform starts new servers and adds them to the load balancer. When traffic falls, it removes them, and you stop paying for them.

That only works if any server can handle any request, so servers must be stateless: nothing important lives on their own disk or in their memory. Sessions go in a database or cache, and uploaded files go in object storage. Managed databases, object storage and functions scale on their own, which is a large part of their appeal.

A worked example: a photo-sharing app

Say you are building a small photo-sharing app. A sensible cloud design uses each building block for the job it is best at:

1. The web API runs on two small servers behind a load balancer, with a scaling rule allowing up to ten.
2. Uploaded photos go into an object storage bucket, never onto a server's disk.
3. Each new upload triggers a function that makes a thumbnail and saves it back to storage.
4. Photo details, such as owner, caption and storage key, go into a managed SQL database.

Here is the API saving a photo to Amazon S3 with Python's boto3 library:

import boto3
 
s3 = boto3.client("s3")
 
def save_photo(user_id, photo_id, data):
    key = f"photos/{user_id}/{photo_id}.jpg"
    s3.put_object(
        Bucket="my-photo-app-uploads",
        Key=key,
        Body=data,
        ContentType="image/jpeg",
    )
    return key

And the function that S3 calls for each new object. The event lists the bucket and key of each file that arrived:

def handler(event, context):
    for record in event["Records"]:
        bucket = record["s3"]["bucket"]["name"]
        key = record["s3"]["object"]["key"]
        make_thumbnail(bucket, key)

The trigger is set to fire only for keys under photos/, and thumbnails are written under thumbs/. Without that split, every thumbnail would trigger the function again, which would make another thumbnail, and so on.

No server holds anything that can't be lost. When a post goes viral, the API scales out, storage absorbs the uploads and the function runs as many copies as it needs. At low traffic, most of the bill is the always-on servers and database.

Trade-offs and when not to use it

• Steady, heavy workloads can cost more. Renting is great for spiky or uncertain traffic. For large, predictable, always-busy workloads, owning or leasing hardware can work out cheaper.
• Bills can surprise you. Charges for data leaving the provider's network, forgotten test resources and runaway scaling all add up quietly.
• Lock-in. The more you lean on one provider's own services, the harder it is to move. Plain virtual machines, containers and standard databases are easier to take elsewhere.
• Rules about data. Some organisations must keep data in a particular country, which limits the regions they can use.
• Providers have outages too. A data centre, or occasionally a whole region, can have problems. Spreading an app across availability zones, which are separate data centres in the same region, covers the first; the second needs more than one region.

Common mistakes

• Public buckets. Storage should be private by default, with access granted on purpose.
• Access keys in code. Credentials committed to a repository get found. Give servers and functions a role with only the permissions they need instead.
• No budget alerts. Set a spending alert on day one, and delete test resources when you finish with them.
• State on the server. Files or sessions stored on one server's disk vanish when that server is scaled away.
• Everything in one zone. A single server in a single data centre goes down with that data centre. Run at least two, in different zones.

Key takeaways

• The cloud is rented computing in someone else's data centre: on demand, elastic and pay-as-you-go.
• Most apps are built from compute, object storage, managed databases and serverless functions.
• The provider runs more of the stack as you move from IaaS to PaaS to SaaS, but securing your own configuration is always your job.
• Scaling out only works when servers are stateless, with data kept in managed storage and databases.
• It is not magic: it is other people's computers, with costs and limits to plan for.