Modernizing Applications with Serverless and Containers

Imagine you run a small e-commerce website that sells custom T-shirts. Five years ago, you would have bought a physical computer server, installed an operating system (like Linux), set up a database, and installed your T-shirt shop application on that one machine. That machine was your 'server'. It ran 24/7, even at 3 AM when nobody was buying T-shirts. You paid electricity bills, you worried about the hard drive crashing, and if you ran a big advertising campaign, you had to buy a second server because the first one couldn't handle the extra customers. That's the old way, and AWS calls it 'undifferentiated heavy lifting' — work that doesn't make your T-shirt shop unique.

Modernising applications means moving away from that model. Instead of managing physical servers, you use two key AWS approaches: containers and serverless. Let us break them down.

Containers are like shipping containers for your code. In the old days, you would pack your application (the code, the settings, the libraries it needs) directly onto the server. If you wanted to move it to a different server, you had to unpack everything and hope it worked the same way. Containers solve this. A container is a lightweight, standalone package that includes your application code plus everything it needs to run — the runtime (like Python or Node.js), the system tools, libraries, all of it. You build this package once, called a 'container image', and you can run it on any machine that has a container engine (like Docker). This means your application behaves identically on your laptop, on a test server, and on AWS. The exam focuses on AWS services like Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). ECS is AWS's own container orchestrator — a tool that automatically starts, stops, and manages your containers across a cluster of virtual machines. EKS does the same job but uses the industry-standard Kubernetes system, which is popular if your company wants to avoid being locked into AWS-only tools.

Serverless is a step further. With serverless, you do not manage any servers at all. You simply upload your code and tell AWS, 'Run this when someone visits my website.' AWS automatically spins up the compute power needed, runs your code, and then shuts it down when it is done. You pay only for the time your code actually runs. The primary service for this is AWS Lambda. Lambda runs short pieces of code (functions) in response to events — like an HTTP request from a user, a file being uploaded to S3, or a message arriving in a queue. AWS handles everything: the operating system, the runtime updates, the scaling, the availability. Lambda functions have a maximum execution time of 15 minutes and are best for stateless tasks — meaning they do not remember anything from one run to the next; all state must be stored elsewhere, like in a database (DynamoDB) or a key-value store (ElastiCache).

Why modernise? Three reasons: cost, agility, and reliability. Cost: you stop paying for idle servers. Agility: you can deploy new features in minutes instead of days. Reliability: if one container or Lambda function fails, AWS automatically starts a new one — your application stays up. The SAP-C02 exam tests your ability to design architectures that combine these services. For example, you might use API Gateway (a managed service for creating REST APIs) to accept web requests, then route them to a Lambda function that processes the request and stores data in DynamoDB. This is called a 'serverless architecture'. Or you might run a containerised microservice — one small part of your application — on ECS, and have it communicate with other microservices via Amazon SQS (a message queue) or Amazon SNS (a notification service).

The key difference to remember for the exam: containers still run on virtual machines (even if you do not see them). You are responsible for patching the container's OS if you use a custom image. Serverless (Lambda) completely abstracts the underlying infrastructure — you never touch the OS. Containers are better for long-running, stateful applications. Serverless is better for event-driven, short-lived tasks. The exam will ask you to choose between them based on requirements like 'requires a persistent connection' (go containers) or 'needs to scale to zero when idle' (go serverless).

An IT professional tasked with modernising their company's legacy application would follow a structured process. Let us say the company is a logistics firm with a monolithic application that tracks package deliveries. The old system runs on a single physical server in their office, and it keeps crashing during peak holiday seasons. Their boss tells them, 'Make it handle 10x the traffic, and do not buy any new hardware.'

The first step is to break the monolith into smaller pieces. The professional analyses the application and identifies distinct components: the user login function, the package tracking map, the customer notification service, and the billing module. These become candidate pieces to run as separate containers or Lambda functions.

Next, they decide on the hosting strategy. For the billing module (which needs a persistent database connection and can run for minutes at a time), they choose containers on Amazon ECS with AWS Fargate. Fargate is a 'serverless compute engine for containers' — it means they do not manage the underlying servers; AWS handles the virtual machines. For the notification service (which fires every time a package is scanned and runs in under a second), they choose AWS Lambda. For the login function, they use Amazon Cognito (a managed identity service) combined with Lambda to verify users.

The practical steps the IT pro takes include:

Finally, they monitor everything. They use Amazon CloudWatch to collect logs and metrics. If the billing container's CPU usage exceeds 80%, CloudWatch triggers a scaling policy that spins up more containers. If a Lambda function throws an error, CloudWatch creates an alarm and sends a message to the operations team via Amazon Simple Notification Service (SNS).

The result: the company now runs on a modern, resilient system. During a peak sale, the number of running containers and Lambda invocations automatically grows to meet demand. When the sale ends, everything scales back down. The IT team no longer wakes up at 3 AM to reboot a server. The exam tests whether the candidate can design this exact flow, choosing the right AWS services and explaining why they are appropriate.