Microservices, REST APIs, and Serverless Computing

The Twelve-Factor App

Modern software is delivered as a service — centrally hosted, accessed over the internet — and the Twelve-Factor App methodology captures the practices that suit this model, especially for microservices. Its factors group into three phases:

Code

• One codebase, tracked in version control, deployed many times
• Build → release → run as three strictly separate stages
• Keep dev and prod environments as similar as possible

Deploy

• Treat every dependency as explicit
• Keep anything that varies between environments in config, not code
• Access local and third-party services uniformly, by URL and credentials
• Keep processes stateless and share-nothing
• Export functionality by binding to a port

Operate

• Scale via disposable, concurrent, stateless processes
• Treat logs as an event stream, captured by the runtime
• Run one-off admin tasks against a release, using the same codebase and config

Microservices vs. monolith vs. SOA

A microservice architecture builds one application from many small, independently deployable services, each owning a single business responsibility and its own technology stack.

	Monolith	SOA	Microservices
Structure	One process, internal layers	Provider/consumer services	Loosely coupled, independent components
Strength	Simple to build	Reliable, parallel development	Scale and evolve independently
Weakness	Complexity grows with size	Complex, expensive design	Larger security surface, harder debugging

Because microservices don't share interdependencies, teams can update, scale, and adopt new technology in one service without touching the others.

Patterns, REST, and API gateways

Common patterns for structuring microservices:

• SPA — one interface that updates dynamically via REST, instead of reloading
• Backend for Frontend (BFF) — one backend per UI type, tailored per channel
• Strangler — replace a monolith's domains with microservices in stages, old and new running side by side
• Service Discovery — lets services find each other as instances change

REST maps cleanly onto CRUD:

POST    -> Create
GET     -> Read
PUT     -> Update
DELETE  -> Delete

An API Gateway sits between clients and this collection of backend services as a single point of contact — protecting, analyzing, and monetizing APIs, at the cost of an extra network hop and a potential single point of failure.

Building and testing APIs

curl -X GET 'http://127.0.0.1:5000/products' -H 'accept: application/json'

• cURL — a command-line tool for transferring data with URLs; great for quick endpoint tests and debugging
• Postman — a full API platform with a GUI, built for team collaboration across the whole API lifecycle
• Swagger / OpenAPI — a standard, language-agnostic way to describe a REST API's operations, inputs, and auth requirements, and generate an interactive UI from it (pip install flask-swagger-ui in Flask)
• GraphQL — lets clients fetch exactly the fields they need through one endpoint, avoiding REST's over- and under-fetching:

query {
  user(id: "1") {
    name
    email
  }
}

Serverless computing

The CNCF defines serverless as building and running applications without managing servers: code ships as functions, uploaded to a platform, and executed, scaled, and billed purely on demand — effectively FaaS (Functions as a Service) plus BaaS (Backend as a Service).

• Hostless, elastic, stateless, event-driven, billed by usage
• Pros: lower cost, faster development, built-in high availability
• Cons: cold starts, vendor lock-in, harder monitoring and debugging, poor fit for long-running processes

✦

Best practice: give each function exactly one responsibility, keep it small and lightweight so it loads fast, avoid chaining many functions together, and limit third-party dependencies — all four directly reduce cold-start time and cost.