Day 13: AWS Solutions Architect Professional Prep — Serverless architectures
Today’s lesson was all about Serverless architectures. Serverless is a method where you simply write your code and let Amazon Web Services (AWS) handle all the maintenance, scaling, and heavy lifting automatically. With serverless you can focus purely on creating amazing features and not managing infrastructure. You don’t have to manage complicated servers and pay for expensive computing power that just sits idle. You only pay when your code is actually running.
Serverless computing can be compared to a vending machine. You just pay for the soda (code execution) right when you need it instead of buying a whole store (a dedicated server) and hiring staff. AWS handles the machine maintenance and stocking.
I delved into three core services namely, Lambda, API Gateway, and EventBridge that require zero server management.
I found answers to 3 key questions:
1. Where does my code actually run? (AWS Lambda)
2. How do customers access my application? (API Gateway)
3. How do different parts of my application talk to each other without breaking? (EventBridge)
1. Where does my code actually run? (AWS Lambda)
AWS Lambda is like a professional chef working on call. The chef is not paid to stand around waiting. The chef only shows up and cooks when someone places an order (the trigger). Likewise, Lambda executes your function code when it is triggered, meaning you don’t have to manage any dedicated computers (EC2 instances or containers).
When configuring Lambda, key parameters include Memory, which proportionally affects CPU and network performance, and Timeout, which can be up to 15 minutes.
But there is a trick to increase performance – Provisioned Concurrency. This is akin to keeping the chef on standby. Since the chef might take a minute to grab ingredients (a “cold start”) Provisioned Concurrency means you pay a bit extra to keep the chef ready at the stove so the meal starts instantly. It keeps the function “warm,” reducing the delay caused by initialization (cold starts).
There are other optimization tips like keeping dependencies small and tuning memory settings. Lambda supports various runtimes like Node.js, Python, and Java, as well as custom runtimes. Like a trustworthy employee, each Lambda function is given only the specific permissions it needs to do its job, following the principle of least privilege.
2. How do customers access my application? (API Gateway)
API Gateway is the official entrance for all incoming requests to an application. It manages all the people coming in and directs their orders to the right Lambda chef. It allows you to build standard REST APIs, faster HTTP APIs, or WebSocket APIs for real-time communication. It helps manage crowds by using Throttling and Quotas to control traffic bursts, so the system isn’t overwhelmed. It can use caching for faster responses to reduce latency and decrease the number of times a Lambda function needs to be invoked.
It is comparable to The maître d’ at a restaurant. This service stands at the front entrance, managing the traffic, checking IDs (security), setting limits on how many people can enter (throttling), and directing guests (requests) to the right kitchen (Lambda function).
3. How do different parts of my application talk to each other without breaking? (EventBridge)
EventBridge is an invisible communication system. Think of the postal service or mail sorter. When one service (like an Order Service) finishes a job, it drops a letter (the event) into the system. EventBridge reads the address (the rule) and routes it efficiently to any other service (the target, like a Payment Service) that needs to know about it. This makes services independent of each other.
If Lambda is the engine that runs your code and AP Gateway is the front door of the application then Eventbridge can be called The Decoupling Glue. EventBridge creates decoupled microservices, that is, if the Shipping Department breaks, the rest of your system (like the Order Entry system) can keep running.Instead of Service A sending a message directly to Service B (creating a tight connection), Service A sends a message to the Event Bus. EventBridge uses Rules to automatically route that message to Service B (the Target).
If the target service is temporarily unavailable, EventBridge will retry the delivery for up to 24 hours to prevent data loss.
To sum it all up, the three services I studied today are said to form the backbone of modern, event-driven, cost-effective serverless architectures. By linking these tools—API Gateway (front door) to Lambda (task runner) to a database like DynamoDB (storage), and using EventBridge (communicator) it becomes possible to build a complete, powerful system without worrying about server maintenance.