Serverless architecture, cost models and case studies notes — Unit 5

Cloud computing evolved from renting physical servers (IaaS), to renting managed platforms (PaaS), to renting container execution environments (CaaS). The final evolution is Serverless Computing (Function as a Service - FaaS).

⇒1.1 The Premise

Despite the name, servers still exist. 'Serverless' means the developer does not provision, manage, or even see the servers. You simply write a function of code (in Python, Node.js, Java) and upload it. The cloud provider handles everything required to execute it.

Serverless functions (like AWS Lambda or Azure Functions) do not run continuously like a web server. They are completely dormant until triggered by an event.

⇒2.1 Triggers

An event could be an HTTP request hitting an API Gateway, a new image being uploaded to an S3 bucket, a new row being added to a database, or a scheduled cron job. When the event occurs, the cloud instantly boots an isolated MicroVM, executes the function code, and then destroys the environment.

• No Server Management: No OS patching, no capacity planning, no SSH access.
• Infinite Auto-Scaling: If 1 request comes in, 1 function executes. If 10,000 requests hit simultaneously, the cloud provider instantly spins up 10,000 parallel instances of your function. You don't configure auto-scaling rules; it is inherently scalable.
• Pay for Execution Only: You are billed by the millisecond of execution time. If your function doesn't run for a month, your bill is $0.00. (Unlike an idle EC2 server which costs money 24/7).

⇒4.1 Cold Starts

When a function hasn't been executed recently, the cloud provider tears down its container. When a new request arrives, it takes time to download the code, initialize the runtime (e.g., load the Java Virtual Machine), and execute. This delay (the Cold Start) can add a few seconds of latency, which may be unacceptable for real-time web applications.

⇒4.2 Vendor Lock-in

Serverless architectures are highly integrated with proprietary cloud events (like AWS DynamoDB streams triggering AWS Lambdas). Moving this logic to Google Cloud requires entirely rewriting the architecture.

Cloud pricing is based on three fundamental drivers: Compute, Storage, and Data Transfer.

⇒5.1 The General Rules

• Data transferred INTO the cloud (Ingress) is usually free.
• Data transferred OUT OF the cloud (Egress) incurs per-GB charges. (Providers want you to put your data there and leave it there).
• Data transferred between different regions (e.g., US to Europe) incurs charges.
• Storage is billed per GB, per month.
• Compute is billed per second or hour of runtime.

• On-Demand: You pay the highest rate, by the second. Use for unpredictable workloads. You can terminate at any time.
• Reserved Instances: You commit to paying for a server for 1 or 3 years. In exchange, you get massive discounts (up to 70%). Use for stable, predictable workloads like a core database.
• Spot Instances: Cloud providers have excess unused servers. They auction them off at a massive discount (up to 90%). However, if someone else bids higher or the provider needs the capacity, your server is terminated with only a 2-minute warning. Used for fault-tolerant, interruptible workloads like batch processing or video rendering.

When executives compare cloud costs to on-premises costs, they often make the mistake of just comparing the cost of a physical server to the hourly rate of a VM. This is flawed.

⇒7.1 Comprehensive TCO

On-premises TCO must include: hardware costs, software licenses, data center real estate, cooling electricity, network switches, physical security guards, and the salaries of the IT staff required to maintain the hardware.

Cloud TCO reduces these physical and personnel costs, shifting the IT staff's focus from hardware maintenance to software innovation.

Because cloud resources can be provisioned by developers instantly via APIs, companies often face massive unexpected bills ('Cloud Shock').

⇒8.1 Cost Optimization Strategies

• Right-Sizing: Many developers provision a large VM 'just in case'. Monitoring tools can identify VMs utilizing only 5% of their CPU and recommend downgrading them to a cheaper size.
• Turn off idle resources: Automatically shutting down development and testing environments on weekends and nights.
• Tagging: Assigning metadata tags (e.g., `Department: Marketing`) to resources to track exactly which team is spending money.

Netflix is the poster child for cloud migration. After a massive database corruption in their own data center in 2008 delayed DVD shipments, they decided to move entirely to AWS.

⇒9.1 The Architectural Shift

They didn't just 'lift and shift' their monolith. They spent 7 years rewriting their entire application into hundreds of stateless microservices.

They heavily utilize Auto Scaling to handle evening prime-time viewing spikes, and AWS S3 to store their petabytes of master video files. They built their own global CDN (Open Connect) to cache the streaming video close to users.

Because the cloud uses commodity hardware, servers WILL fail. Netflix embraced this reality by inventing Chaos Engineering.

⇒10.1 Simulating Disaster

They created a software tool called 'Chaos Monkey' that runs in their production cloud environment and randomly terminates random Virtual Machines during business hours.

This forces their engineers to design software that is incredibly resilient. If the architecture is truly stateless and auto-scaling, terminating a random server causes zero downtime for the users. Later, they created 'Chaos Gorilla' to simulate an entire AWS datacenter going offline.

Banks are notoriously conservative due to strict regulations, preferring massive mainframes in private data centers. Capital One made headlines by announcing an 'All-in' strategy on the public cloud (AWS).

⇒11.1 Security and Innovation

They realized they could operate more securely in the cloud than in their own data centers by leveraging AWS KMS, strict IAM policies, and automated compliance monitoring. Moving to the cloud allowed their developers to provision infrastructure in minutes instead of months, rapidly speeding up the rollout of their mobile banking apps.

A Cloud Guru (an online training platform) was built from day one entirely on Serverless architecture (AWS Lambda, API Gateway, DynamoDB).

⇒12.1 The Result

Because they had no servers to maintain, they didn't need to hire DevOps engineers. Because they only paid when users actually clicked play on a video (executing a Lambda function), their hosting costs for a global user base of tens of thousands were literally a few hundred dollars a month.

When they experienced massive traffic spikes after being featured on a news site, the serverless architecture scaled instantly to handle the load without anyone touching a keyboard.

Anti-patterns are common ways organizations fail when adopting cloud technology.

⇒13.1 Lift and Shift

Taking a monolithic, stateful application from a private data center and simply installing it on an IaaS VM in the cloud. You gain none of the elasticity, auto-scaling, or PaaS benefits, and you usually end up paying MORE money than before.

⇒13.2 Treating Cloud VMs like Pets

In the old days, servers were 'pets' (given names, carefully nursed back to health when sick). In the cloud, servers should be 'cattle' (numbered, identical, and if one gets sick, you destroy it and spawn a new one).

⇒14.1 Edge Computing

To reduce latency for IoT devices, Edge computing pushes processing power out of the central cloud and closer to the data source (e.g., computing on the cell tower, or on the IoT device itself).

⇒14.2 Green Cloud Computing

Major cloud providers are moving toward 100% renewable energy. Because public clouds operate at massive scale with custom-designed hardware, they are significantly more energy-efficient than typical corporate data centers.