Serverless and cloud-native applications

In short

Serverless computing lets a developer deploy individual functions or managed services without provisioning, scaling or patching servers; the cloud provider allocates compute per request and bills only for actual execution. Cloud-native is the broader design style — applications built as loosely coupled, containerised, independently deployable microservices that assume failure, scale horizontally and are managed through automation. Together they are the standard architecture for Indian SaaS and fintech products (Razorpay, Zerodha, Swiggy, Meesho, CRED) and for government platforms built on MeghRaj and the NIC cloud. MCA syllabi examine serverless under cloud computing and advanced web/mobile backends, and GATE DA/CS touches it through distributed systems and virtualisation. Placement rounds ask it as design questions: "how would you build an image-thumbnail service without a server?"

Explained

From physical servers to serverless: the service models

• IaaS — provider gives virtual machines, storage, network (EC2, Azure VM). The user manages OS, runtime, scaling, patching.
• PaaS — provider manages OS and runtime; user deploys an application (Elastic Beanstalk, App Engine standard). Still billed for an always-on instance.
• CaaS — containers as the unit (ECS, AKS, GKE); user manages images and orchestration config.
• FaaS (Function as a Service) — the user uploads a *function*; the provider runs it on an event, scales 0→N and back to 0, bills per invocation and per GB-second. This is serverless compute.
• BaaS (Backend as a Service) — ready-made managed backend features: authentication, database, push, storage (Firebase Authentication, Firestore, AWS Cognito, Amplify). Serverless = FaaS + BaaS.
• Serverless does not mean "no servers" — it means no server *management* and no idle cost. Servers exist; responsibility for them has moved to the provider.
• Shared-responsibility shift: the lower the layer the provider owns, the less operational control the developer has — the trade is convenience for lock-in.

How a FaaS platform executes a function

1. Deploy: code + dependencies are packaged (zip or container image) with a handler name, memory size, timeout and IAM role.
2. Trigger: an event source fires — HTTP call through API Gateway, object upload to S3/Blob Storage, message on SQS/Kafka/Pub-Sub, DB stream (DynamoDB Streams), cron (EventBridge/Cloud Scheduler), IoT or mobile SDK call.
3. Cold start: no warm sandbox exists, so the platform allocates a microVM (AWS uses Firecracker), downloads the package, starts the runtime and runs any initialisation code outside the handler.
4. Warm invoke: the sandbox is reused for subsequent events — initialisation is skipped, so latency drops to the handler's own execution time.
5. Concurrency: each concurrent event gets its own sandbox; one sandbox handles exactly one request at a time (no in-process threading model like a web server).
6. Freeze/thaw: after a response the container is frozen, kept for a few minutes, then reclaimed. Anything in local /tmp or in memory may or may not survive — never rely on it.
7. Billing: rounded execution time (AWS bills in 1 ms units) × memory allocated, plus a per-request charge. CPU and network scale with the memory setting.

Cold start mitigation: keep packages small, move heavy imports and DB clients to module scope (reused when warm), choose a fast runtime (Go, Node, Python start far quicker than a JVM without AOT), use provisioned concurrency/minimum instances, or SnapStart for Java. Keeping connections to a traditional RDBMS is the classic problem — hundreds of sandboxes exhaust the connection pool, so a proxy (RDS Proxy) or an HTTP-native data store is used.

Serverless design patterns and constraints

• Stateless functions: all state lives outside — object store, managed NoSQL (DynamoDB, Firestore), cache (ElastiCache, Redis), or a queue.
• Event-driven / fan-out: one upload triggers several independent functions via a topic (SNS) or stream.
• Orchestration vs choreography: Step Functions/Durable Functions/Cloud Workflows define a state machine for long or multi-step jobs; choreography lets services react to each other's events with no central coordinator.
• Idempotency: at-least-once delivery is the norm, so a function may run twice for the same event. Deduplicate on an event id stored in the DB.
• Backend-for-frontend and strangler-fig migration: put API Gateway in front of a legacy monolith and move one route at a time to a function.
• Limits to quote in exams: execution timeout (AWS Lambda 15 minutes), package size, memory ceiling (10 GB on Lambda), payload size, per-account concurrency quota with a burst limit. Exact numbers change by provider and region — state them as "of the order of" unless certain.
• Not suitable for: long-running batch or video transcoding beyond the timeout, very low-latency trading paths (cold starts), steady high-volume constant load (a reserved VM or container is usually cheaper), workloads needing special hardware or a persistent in-memory dataset.

Cloud-native: the twelve-factor app and CNCF stack

The twelve factors (Heroku, 2011) are the standard exam list: 1 Codebase in version control, 2 Declared dependencies, 3 Config in the environment, 4 Backing services as attached resources, 5 Separate build/release/run stages, 6 Stateless processes, 7 Port binding, 8 Concurrency by process model, 9 Disposability (fast start, graceful shutdown), 10 Dev/prod parity, 11 Logs as event streams, 12 Admin tasks as one-off processes.

• CNCF definition: cloud-native technologies build scalable applications in modern dynamic environments using containers, service meshes, microservices, immutable infrastructure and declarative APIs — loosely coupled, resilient, observable systems changed frequently with low effort.
• Microservices: one bounded business capability per service, its own datastore, independent deploy and scale; cost is network latency, distributed transactions and operational complexity.
• Supporting pieces: service discovery, API gateway, service mesh (Istio, Linkerd — mTLS, retries, traffic splitting via sidecars), configuration/secret management, message broker.
• Resilience patterns: retry with exponential backoff and jitter, circuit breaker, bulkhead, timeout, rate limit, graceful degradation.
• Observability — three pillars: metrics (Prometheus), logs (Fluent Bit/ELK), distributed traces (OpenTelemetry, Jaeger) correlated by a trace id.
• Delivery: immutable container images, declarative manifests, GitOps (Argo CD, Flux), blue-green and canary releases, infrastructure as code (Terraform, CloudFormation, Pulumi).
• Serverless containers / Knative: Cloud Run and Knative on Kubernetes scale containers to zero and start them on request; AWS Fargate removes node management and bills only for running tasks, but does not scale to zero per request — the middle ground between FaaS and Kubernetes deployments.

Comparison, cost and security

• Economics: serverless wins when utilisation is low or bursty; a break-even point exists beyond which a reserved instance is cheaper (computed in the examples below). Cost also shifts to the managed services around the function — API Gateway requests, NAT gateway data, log ingestion often exceed the compute bill.
• Security: least-privilege IAM role per function, secrets in a secret manager (never in environment variables in plain text for sensitive values), validate every event as untrusted input (event injection), dependency scanning (the largest real risk is a vulnerable library), VPC placement for private resources, WAF on the gateway.
• Indian regulatory context: the DPDP Act, 2023 with the DPDP Rules, 2025 governs personal data — the Data Fiduciary duties (notice, consent, breach intimation, erasure) and the omission of IT Act s.43A take effect only from 13 May 2027; until then IT Act s.43A and the SPDI Rules, 2011 apply, so reasonable security practices on any cloud backend are already a legal requirement. RBI requires regulated entities' payment data to be stored in India (2018 storage directive) and issued a Master Direction on IT Governance, Risk, Controls and Assurance Practices for outsourcing and cloud use. CERT-In's April 2022 directions require incident reporting within 6 hours and log retention for 180 days within Indian jurisdiction — relevant because serverless logs sit in provider-managed stores. MeitY's empanelment of cloud service providers (GI Cloud / MeghRaj) governs government workloads; empanelment is required for government procurement, not for private industry.

Key points

• Serverless - no server provisioning or management, automatic scaling including to zero, pay only for execution.
• FaaS - the compute part of serverless: short-lived, stateless, event-triggered functions (Lambda, Azure Functions, Cloud Functions, Cloudflare Workers).
• BaaS - managed backend features (auth, DB, storage) consumed as APIs; Firebase is the classic mobile example.
• Cold start - latency of creating a new execution environment; mitigated by small packages, warm runtimes and provisioned concurrency.
• Stateless - a function keeps nothing durable between invocations; state goes to S3, DynamoDB or a cache.
• Event source - HTTP, object storage, queue, stream, DB change, schedule or IoT message triggering the function.
• Concurrency - one sandbox per simultaneous request; the account quota, not the code, caps throughput.
• Idempotency - mandatory, because event delivery is at-least-once and retries are automatic.
• Orchestration - Step Functions/Durable Functions model multi-step workflows that exceed one function's scope or timeout.
• Twelve-factor app - the checklist (config in environment, stateless processes, logs as streams, disposability) for a cloud-ready application.
• Cloud-native - containers + microservices + declarative APIs + immutable infrastructure + automation, per the CNCF definition.
• Service mesh - sidecar layer giving mTLS, retries, timeouts and traffic shifting without changing application code.
• Observability - metrics, logs and traces together; a trace id correlates one request across many services.
• Circuit breaker - stops calling a failing dependency after a threshold, so failure does not cascade.
• Knative / Cloud Run / Fargate - serverless containers without the function programming model or vendor runtime; Knative and Cloud Run scale to zero, Fargate only removes node management.
• Lock-in - the main architectural cost of FaaS; containers and open standards (Knative, OpenTelemetry) reduce it.
• Break-even - constant heavy load is usually cheaper on reserved compute than on per-invocation billing.
• Compliance - DPDP Act, 2023 (Rules effective 13 May 2027 for Fiduciary duties; until then IT Act s.43A and SPDI Rules), RBI data localisation, CERT-In 6-hour reporting, MeitY empanelment for government cloud.

Formulas and examples

1. Cost of a thumbnail service (GB-second arithmetic). A function with 512 MB memory runs 400 ms, called 2,000,000 times a month. Take rates of $0.0000166667 per GB-s and $0.20 per million requests (public AWS Lambda list rates; always re-check the current region price).

• M = 512/1024 = 0.5 GB; T = 0.4 s → GB-s per invocation = 0.2.
• Total GB-s = 2,000,000 × 0.2 = 400,000.
• Compute = 400,000 × 0.0000166667 = $6.67.
• Requests = 2 × $0.20 = $0.40. Total ≈ $7.07/month ≈ ₹625 at ₹88/$ (rate varies).
• Note: the free tier (1 M requests, 400,000 GB-s per month) would make this nearly free; quote the tier only as "a monthly free allowance exists".

2. Does more memory cost more? (the counter-intuitive result.) Same function at 1,024 MB finishes in 180 ms because CPU scales with memory.

• 512 MB: 0.5 × 0.400 = 0.200 GB-s.
• 1,024 MB: 1.0 × 0.180 = 0.180 GB-s → 10% cheaper and 2.2× faster.
• Lesson: tune memory empirically (AWS Lambda Power Tuning); the cheapest setting is often not the smallest.

3. Serverless vs a reserved instance — break-even. An API handler uses 256 MB and 100 ms. An always-on t3.small-class VM costs about $0.0208/h.

• Monthly VM cost = 0.0208 × 730 = $15.18.
• Per invocation: GB-s = 0.25 × 0.1 = 0.025 → compute $0.000000417; request $0.0000002 → $0.000000617.
• N* = 15.18 / 0.000000617 ≈ 24.6 million invocations/month ≈ 9.5 requests/s sustained.
• Below roughly 9–10 req/s continuous the function is cheaper; above it the VM is — before counting the VM's patching, monitoring and on-call effort, which is why many Indian startups still choose serverless past the break-even.

4. Concurrency and throttling (Little's law). A results portal gets 5,000 requests/s during a result announcement; each function call takes 250 ms.

• C = 5,000 × 0.25 = 1,250 concurrent executions.
• With a default account quota of about 1,000 concurrent executions, requests are throttled with HTTP 429 → request a quota increase, shorten duration, or buffer through SQS.
• If duration is cut to 100 ms: C = 5,000 × 0.1 = 500 — concurrency need and the GB-second bill fall in direct proportion to duration (here 250 ms → 100 ms, so both drop to 40%), cutting the throttle risk.

5. Cold-start impact on average latency. 10,000 invocations, 300 of them cold. Cold start adds 900 ms; warm execution is 120 ms.

• p_cold = 300/10,000 = 0.03.
• Average = 0.03 × (900 + 120) + 0.97 × 120 = 30.6 + 116.4 = 147 ms.
• The mean looks fine but p99 is dominated by the 1,020 ms cold path — report percentiles, not averages, in an SLA.

# AWS Lambda handler: S3 upload -> thumbnail -> S3, idempotent
import os, boto3
from PIL import Image          # module scope: reused on warm invokes
s3 = boto3.client("s3")        # client created once per sandbox
DEST = os.environ["DEST_BUCKET"]   # config from environment (factor 3)

def handler(event, context):
    for rec in event["Records"]:                 # at-least-once: may repeat
        src, key = rec["s3"]["bucket"]["name"], rec["s3"]["object"]["key"]
        out = f"thumbs/{key}"
        try:
            s3.head_object(Bucket=DEST, Key=out)  # already done -> skip
            continue
        except s3.exceptions.ClientError:
            pass
        body = s3.get_object(Bucket=src, Key=key)["Body"]
        img = Image.open(body); img.thumbnail((200, 200))
        tmp = f"/tmp/{os.path.basename(key)}"     # /tmp is ephemeral
        img.save(tmp, "JPEG")
        s3.upload_file(tmp, DEST, out)
    return {"statusCode": 200}

Where it is used

• Indian fintech and payments: Razorpay, PhonePe and Zerodha run cloud-native microservices with event-driven serverless pieces for webhooks, reconciliation files, notifications and KYC document processing — under RBI localisation and audit rules.
• Consumer internet at scale: Swiggy, Zomato, Meesho, Dream11 and Hotstar use containers plus serverless for burst work — IPL or sale-day traffic, image and video pipelines, coupon and notification fan-out.
• Mobile backends: Firebase/Amplify for authentication, Firestore, push notifications and analytics in Flutter and Kotlin apps built by small Indian studios and startups.
• Government and public digital infrastructure: NIC and MeitY-empanelled clouds (MeghRaj), DigiLocker-style document services, state result and recruitment portals that face extreme one-day spikes — the ideal serverless load shape.
• IT services and GCCs: TCS, Infosys, Wipro, Accenture, Deloitte and captive centres migrate client monoliths to AWS/Azure/GCP; "cloud-native application modernisation" is a standard service line with serverless modules.
• Job roles: cloud engineer, DevOps/SRE, backend engineer (Node/Python/Go/Java), solution architect; certifications employers screen for include AWS Developer/Solutions Architect Associate, Azure AZ-204/AZ-305 and Google Professional Cloud Developer.

Interview questions

• Q: If there are still servers, why is it called serverless? A: Because the developer never provisions, scales or patches them and pays nothing when idle — server management, not the server, has disappeared from the developer's responsibility.
• Q: What is a cold start and how do you reduce it? A: The extra latency of creating a fresh execution environment and runtime; reduce it with small deployment packages, lightweight runtimes, initialisation outside the handler, provisioned concurrency or SnapStart.
• Q: Why must a serverless function be stateless? A: Each invocation may land on a new sandbox and sandboxes are frozen and destroyed unpredictably, so any state kept in memory or /tmp can vanish; durable state belongs in a database, cache or object store.
• Q: How do you make a function idempotent? A: Derive a key from the event (message id, object key, request id), record processed keys in a store with a conditional write, and skip or return the earlier result on a repeat.
• Q: Why do serverless functions break relational databases, and what is the fix? A: Thousands of parallel sandboxes each open connections and exhaust the pool; use a connection proxy such as RDS Proxy, a serverless database with an HTTP data API, or batch through a queue.
• Q: When would you choose containers over FaaS? A: For steady high load (cheaper per request), jobs longer than the function timeout, custom runtimes or hardware, latency-critical paths, and when portability across clouds matters.
• Q: Name the twelve-factor rules most often violated in practice. A: Config hardcoded instead of read from the environment, processes holding session state in memory, and logs written to local files instead of being streamed as events.
• Q: What does a service mesh give you that a library cannot? A: Language-independent mTLS, retries, timeouts, traffic splitting and telemetry applied uniformly through sidecars, without changing or redeploying application code.
• Q: Explain the difference between orchestration and choreography in event-driven systems. A: Orchestration uses a central workflow engine that calls each step and holds the state; choreography has services publish and react to events with no coordinator — simpler to scale, harder to trace.
• Q: How do you debug a failure that spans six microservices? A: Propagate a trace id through all calls and use distributed tracing (OpenTelemetry/Jaeger) with correlated structured logs and metrics to find the failing span.
• Q: Is serverless always cheaper? A: No — it is cheaper for bursty or low-utilisation workloads; past a break-even invocation volume reserved containers or VMs cost less, and surrounding managed services (gateway, NAT, logs) often dominate the bill.
• Q: What are the compliance concerns for an Indian fintech going serverless? A: RBI's requirement to store payment data in India, CERT-In's 6-hour incident reporting and 180-day log retention, and the DPDP Act, 2023 framework — whose Data Fiduciary duties under the 2025 Rules apply from 13 May 2027, with IT Act s.43A and the SPDI Rules applying until then.

Common mistakes

• Writing "serverless means no servers are used" in an exam answer instead of "no server management and no idle cost".
• Storing session state, counters or uploaded files in a function's memory or /tmp and assuming the next invocation will find them.
• Assuming exactly-once delivery and omitting idempotency, so a retried event double-charges a customer or sends two SMS messages.
• Treating lower memory as automatically cheaper — CPU scales with memory, so a bigger setting can finish faster and cost less (worked example 2).
• Mixing up FaaS and BaaS, or calling a managed Kubernetes cluster "serverless" when it keeps a minimum of one running node.
• Opening a new database connection inside the handler on every invocation, and creating heavy SDK clients inside the handler instead of at module scope.
• Reciting the twelve factors as a list without being able to say what breaks when one is violated, and quoting provider limits (timeout, memory, concurrency) as fixed when they differ by provider and change over time.

Related topics

Cloud computing basics · Containers: Docker and Kubernetes · DevOps and CI/CD basics · Information security fundamentals · Cross-platform apps: Flutter and React Native · Machine learning workflow