Defying Serverless Constraints Real-life Serverless Workarounds Allan Chua Feb 2025 L400 | Serverless | AWS Singapore User Group

About Me • Serverless Since 2019 • 4 AWS Certs • AWS Community Builders • AWS Singapore UG Volunteer • CTO @ Premier Fiduciary

Code Samples https://github.com/allanchua101/defying-serverless-constraints-demo

This Presentation is About Serverless API Archetypes Constraints Solutioning Options Pros & Cons Analysis

What’s Covered AWS Lambda API Gateway SAM Rest APIs Cloud Formation Node JS

What’s Not Covered Event-Driven Architecture (EDA) TypeScript Storage Services

Serverless API Archetypes

Micro-Lambdas API Gateway GET /INVOICES GET /INVOICES/{ID} POST /INVOICES/{ID} GET /PAYMENTS GET /PAYMENTS/{ID} POST /PAYMENTS/{ID} Single purpose functions that serves requests for a single REST endpoint. • Least Change Collisions on Code • Easier to Maintain • Easiest to Debug • Good for Small Apps and POCs PROS • Most Change Collisions on SAM file • Death by YAML • Plenty of Short Cold Starts • Scaling Constraints CONS

Maximum Number of Resources Inside a Cloud Formation Stack 500 Accurate as of Feb 19, 2025

Gateway-Lambda Integration Anatomy Input Output Lambda Function Function Execution Role Function Invocation Permission

5 API Gateway CF Resources (Stage, Deployment, Rest API, Domain Name, Path Mapping) Maximum # of APIs built on top of Micro-Lambdas per CF Stack ((500 – 5) / 3) = 165 Lambda Functions 1 API Function = 3 Resources 500 Max Resource Count

It used to be lower back @ 2019 LLMs are not mainstream during this period ((200 – 5) / 3) = 65 Functions for APIs

Max # of Resources Inside a Cloud Formation Stack Solutioning Options Refactor to Lambda-Lith Group Resources into Nested CF Stacks Split Resources into Logical Stacks Go back to Docker and K8s

Splitting Resources into Logical Groups Reactors/ BG Workers Lambda Functions APIs Lambda Functions API Gateway Core S3 SQS DynamoDB IAM Roles Do! Core, Reactors, BG Workers and APIs S3 SQS DynamoDB IAM Roles Don’t Lambda Functions API Gateway

Reactors/ BG Workers Lambda Functions APIs Lambda Functions API Gateway Core S3 SQS DynamoDB IAM Roles This is decent but… • Scaling Bottleneck at the Compute Stack CONS • Larger Max Resource Constraint • Faster Deployments • Makes Compute Layer Refactorable • Less Risk of Deleting DBs PROS

Dillussional Solution Reactors/ BG Workers Lambda Functions Core S3 SQS DynamoDB IAM Roles Notification APIs API Gateway Payment APIs Invoicing APIs Billing APIs Auth APIs Notification APIs

But You Can't Reference API Gateways from another CloudFormation Stack when using SAM Problem since 2018

Nesting CloudFormation Stacks Superior Option for Scaling Reactors/ BG Workers Lambda Functions Payment APIs API Gateway Core S3 SQS DynamoDB IAM Roles Invoicing APIs API Gateway Auth APIs API Gateway Notification APIs API Gateway Correspondence APIs API Gateway Company APIs API Gateway

Maximum Number of API Gateways Accurate as of Feb 19, 2025 ACCOUNT-LEVEL | NON-ADJUSTABLE 600 Regional 120 Edge-optimized

Routes per API Gateway GATEWAY-LEVEL | SOFT LIMIT Accurate as of Feb 19, 2025 300 36K Edge Optimized APIs 180K Edge Optimized APIs

Maximum Number of IAM Roles per Account ACCOUNT-LEVEL Accurate as of Feb 19, 2025 1000 SOFT LIMIT 5000 HARD LIMIT

AWS Service Quotas Are Adjustable They are Not Portable

AWS Service Quotas Are Adjustable But Not Portable DEV UAT PRD “It Works in my Account“

Max # of API Gateways, IAM Roles, SAM Issues Solutioning Options Refactor to Lambda-Lith Merge APIs (Bounded Context) Go back to Docker and K8s

Lambda-Lith GET /INVOICES GET /INVOICES/{ID} POST /INVOICES/{ID} POST /PAYMENTS/{ID} GET /PAYMENTS/{ID} GET /PAYMENTS https://middy.js.org/ https://hono.dev/ API Gateway ANY /{proxy+} GREEDY PATH Just like our traditional APIs where a single server process is in-charge of responding to all endpoints in a REST API.

https://middy.js.org/ Middy

https://hono.dev/ HONO

API Routing Frameworks for AWS Lambda - AWESOME for strangler migrations - Lowest Barrier of Entry - Gets Rid of Micro-lambda Scaling Issues - Least YAML Coding - Faster Deployment - Frequent Warm Starts - Great for Medium-sized Apps PROS - Higher Risk of Breakage - Single Point of Failure - Slower Response Times - Harder to Debug - Heavy Cold Start - Simple CRUD functions have to be loaded with SDKs used by Reporting APIs - Scaling Issues CONS

Lambda Function Maximum Package Size (Zipped) FUNCTION-LEVEL | HARD-LIMIT Accurate as of Feb 19, 2025 50 MB

Modu-Lith API Gateway ANY /PAYMENTS/{proxy+} ANY /INVOICES/{proxy+} ANY /PURCHASE-ORDERS/{proxy+} - Frequent Warm Starts - Awesome for Large-scale API Development - Smaller Blast Radiuses - Low YAML Amount - Low Barrier of Entry - Low IAM Role Count - Simple CRUD APIs don’t need to load heavy SDKs used by reporting APIs PROS - AKA Modular Monoliths - 1 Greedy Path per Module - 1 Function for each Module - Duplicated Libraries Across Functions - Lower amount of code samples & literature CONS ANY /REPORTS/{proxy+} POST /PAYMENTS/{ID} GET /PAYMENTS/{ID} GET /PAYMENTS GET /INVOICES GET /INVOICES/{ID} POST /INVOICES/{ID} GET /PURCHASE-ORDERS GET /PURCHASE-ORDERS/{ID} POST /PURCHASE-ORDERS/{ID} GET /REPORTS GET /REPORTS/{ID} POST /REPORTS/{ID}

Runtime Lifespan

Serverless Ops Myth “AWS will take care of trivial Ops work for my Lambda Functions”

Upgrading Function Runtimes Consumes Manpower Responsibility is Shared

NodeJS Runtime Calendar http://bit.ly/42X2cPW

NodeJS Runtime Block Function Creation Calendar Feb 2025 16 Oct 2025 18 Jun 2026 20 22 Jun 2027

Function Runtime Upgrades and Monitoring Required https://allanchua101.github.io/sana/

Helps you monitor function upgrade progress

Conclusion • Micro-lambdas are great for prototyping. • Spread your CF Resources into Logical Groups • Lambda-lith offers low entry barrier to Serverless. • Modulith Offers Extreme Code-base Scaling • Runtimes Expire and Require Routine Upgrades

5 Minutes Q&A Session

Feedback