Serverless and Deploying Apps to the Cloud: Functions, Containers and CI/CD

Every developer remembers the first time someone else opened their app on their own phone. This lesson gets you there — and explains the options, so you pick the right one instead of the first tutorial you find.

Four ways to run an app in the cloud

Move down the table only when you need to. Each step gives more control and more work.

What "serverless" really means

There are still servers — you just never see or manage them. You upload a function; the provider runs it when an event happens and bills you per request and per millisecond of run time. With no traffic, cost is close to zero.

Events can be: an HTTP request, a file uploaded to a bucket, a message in a queue, a database change or a timer ("every day at 7 am").

# A serverless function (AWS Lambda style): resize an image whenever a student uploads a profile photo
def handler(event, context):
    record = event["Records"][0]
    bucket = record["s3"]["bucket"]["name"]
    key    = record["s3"]["object"]["key"]
    make_thumbnail(bucket, key, size=(200, 200))      # your own function
    return {"status": "ok", "file": key}

Serverless trade-offs

• Cold starts — the first request after a quiet period can be slower while the platform starts your function.
• Time and memory limits — long-running jobs fit better in containers.
• Statelessness — nothing is kept between calls; store state in a database or object storage.
• Cost at high steady traffic — per-request pricing can exceed an always-on container for constant heavy load.

A realistic first deployment

For a typical student project — a React frontend and a Python API — this setup is simple, cheap and professional:

Frontend (React build)  →  static hosting + CDN
API (Flask / FastAPI)   →  container platform (e.g. Cloud Run) — scales to zero when idle
Database                →  managed PostgreSQL / MySQL (free tier or smallest size)
Secrets                 →  the platform's secret manager, injected as environment variables

Deploying the API is often three commands: build the container image, push it to the registry, and tell the platform to run that image. The platform gives you an HTTPS URL.

CI/CD: deploy on every push

Continuous Integration runs your tests automatically on every change. Continuous Delivery/Deployment builds and deploys passing changes automatically. Together they remove "it worked when I deployed manually last Tuesday" problems.

# .github/workflows/deploy.yml — a simplified pipeline
name: test-and-deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - run: pip install -r requirements.txt && pytest          # stop here if tests fail
      - run: docker build -t $IMAGE .                            # IMAGE and credentials come from repository secrets
      - run: docker push $IMAGE
      - run: ./deploy.sh $IMAGE                                  # the provider's CLI command to roll out the new image

Deployment strategies

• Rolling — replace instances a few at a time. The default on most platforms.
• Blue-green — run the new version alongside the old, switch traffic over at once, switch back instantly if something breaks.
• Canary — send 5% of traffic to the new version first, watch errors, then increase.

After it is live

Turn on the platform's logs, set an alert for error rates and for when the service is down, and add a simple health-check endpoint (/health) the platform can poll. Knowing your app is broken before your users tell you is the mark of a professional.