DEV Community: S Uma Shankar Reddy

Day3 Lab with Serveless development.Getting into the Serverless Mindset

S Uma Shankar Reddy — Fri, 14 Aug 2026 07:27:41 +0000

If you were to build a simple web service today, you might instinctively deploy a web application on a single server, like an Amazon EC2 instance, connected to a database. As traffic grows, you'd add a load balancer, set up an Auto Scaling group, and spread your instances across multiple availability zones.

This traditional architecture is proven and common. But it also comes with a lot of "undifferentiated heavy lifting"—managing host configurations, patching operating systems, and monitoring server health. These tasks are critical, but they aren't unique to your business.

What if you could hand all of that over to AWS? Enter the serverless mindset.

The 4 Pillars of Serverless

When we talk about an architecture being "serverless," we are referring to four core characteristics:

No Server Management: You never have to provision, patch, or manage hosts.
Flexible Scaling: The platform scales automatically based on the unit of work (e.g., database reads/writes or HTTP requests), not CPU or memory.
Automated High Availability: Fault tolerance is baked into the platform by default. You don't have to engineer your way around single points of failure.
Never Pay for Idle: You are only charged for the exact compute time you consume. If a function runs for 300 milliseconds, you pay for 300 milliseconds. If there's no traffic, you pay nothing for compute.

Changing How You Think About Applications

Migrating from a server-based model to a serverless one requires a few fundamental paradigm shifts:

1. Shift to Event-Driven Design

In a traditional model, you might ask, "What data am I storing, and what operations do I perform against it?"

In a serverless world, you need to ask, "What events should trigger an action in my system?"
Everything becomes an event. An HTTP request, a new file dropped in an S3 bucket, or a change in a DynamoDB table can automatically trigger an AWS Lambda function to execute your custom business logic.

2. Embrace Managed Services

Don't just rely on Lambda; leverage the broader AWS serverless ecosystem to handle primitive application concerns.

Use Amazon API Gateway to manage restful APIs, authentication, and throttling.
Use Amazon DynamoDB or S3 instead of managing your own database clusters.
Use AWS Step Functions to coordinate microservices without writing custom code for retries or error handling.

3. Unlock Massive Parallelization

Because you never pay for idle capacity, you no longer have to worry about over-provisioning servers for highly parallel tasks.

Take video transcoding as an example. Traditionally, a single server might process a video file serially over 4 to 6 hours. By using serverless architecture, you can split that video into tiny time-slices, spin up thousands of Lambda functions to process them concurrently, and merge them back together.

The result? A 4-hour job drops to 10 minutes, and because of Lambda's pricing model, it often costs significantly less than maintaining the infrastructure to do it the old way.

The Bottom Line

Serverless amplifies the benefits of cloud computing. By removing the burden of infrastructure management, it drastically lowers operational costs and eliminates the waste of paying for idle CPU cycles. But most importantly, it gives your engineering teams their time back—allowing them to stop managing servers and start focusing on the code that actually differentiates your business.

Day 2 with AWS skill builder topic is Serverless Development

S Uma Shankar Reddy — Thu, 13 Aug 2026 07:06:34 +0000

get started developing applications for the AWS serverless platform and how your life as a developer changes when you move from a traditional application development environment to a serverless one.

There are a number of benefits that our customers realize when moving to a serverless architecture, including an improved cost model for their infrastructure and the ability to scale their costs along with the usage of their application.

The AWS serverless platform is comprised of a number of different services that take care of everything from compute to api management, data persistence and messaging. In this course will be focused on the AWS Lambda service, which is a serverless compute platform that allows you to bring your own code.

Now this course assumes that you're already familiar with the basics of the AWS Lambda service. But to review, AWS Lambda allows you to bring your own code and have it run in response to events. So, when an event source triggers your function, your code is run and it can interact with other downstream services such as databases and message streams.

Now it's important to understand that the permission model for Lambda has two different components.

On the front end the event sources that are allowed to trigger your Lambda function are controlled by an IAM resource policy and the resources that your function is allowed to interact with are controlled by the execution role.

So, if you were to have an Amazon S3 bucket triggering a Lambda function, which then put some data into a DynamoDB table for instance, the Amazon S3 permissions to invoke the function would be managed by the resource policy, while the DynamoDB access for your code itself would be managed by the execution role.

WRITE LAMBDA FUNCTIONS

So, let's get started by taking a look at some of the best practices for writing code for Lambda functions. Oftentimes when developers get started with AWS Lambda, they use the AWS Management Console to write their first functions.

However, when you start developing production applications, it's important to move away from that initial experimental kind of phase and start using standard application development tools and practices that you're used to.

One of the most important lessons to take away from this is that all of the best practices that you've learned about software development still apply when it comes to developing serverless applications. You should still be writing good quality, object-oriented code and build and deploy your applications using standard industry practices.

So, let's talk a little bit about how you might organize the code within your Lambda function. Every Lambda function has a handler method. You can think of a handler method, like a main method in a JAVA application. And remember that when you're building Lambda functions, just like it doesn't make sense to include all of the business logic and all of the code for your application into a single main method, you should also be splitting up the functionality of your Lambda functions into multiple classes and functions that are called from that primary entry point.

A typical layout for a Lambda function might look something like this, where we divide the functionality into multiple layers. It starts with the handler function that we just talked about where you would set up your function configuration. Any of the Lambda specific code needed to integrate with the Lambda runtime should go here, but you shouldn't include any of the actual business logic for the function in the entry point itself.

Instead, you would put that business logic into a controller class that's responsible for handling the actual event itself and doing all of the business specific functionality for that particular method.

Finally, service classes can be used to abstract away any external services that your function needs to interface with and provide business interfaces into those external services.

MANAGING SERVERLESS APPLICATION

Transcript
–
So now that we've taken a look at some of the best practices for writing code for your Lambda function, let's talk a little bit about the overall development work flow that's necessary when you move from a traditional application environment into a serverless model.

Just like we talked about, the best practices for writing code when it comes to using Lambda don't really change from a traditional application development world. Also, the tool chain that you're using shouldn't have to change much, either. You should still be using standard source control, IDEs. build and deployment tools when you're building functions in Lambda as you would when you're building traditional applications.

The one addition to that is using a serverless application framework to help manage all of the components of the application. In a traditional application, you would typically use a build tool like Maven or Gradle to create a compiled application binary that then goes and gets deployed onto a cluster of servers. In the serverless world, there's an additional step where you need to package and deploy your code out to the Lambda service, and you're probably going to be breaking your code up across multiple different Lambda functions and resources. And this is where an application framework really becomes valuable.

Typically, when you're deploying a serverless application, there are a number of different steps required in order to actually move from development into a running application. This includes building the code, zipping it up, sending it to Amazon S3, managing all of the different execution roles, and IAM policies, creating the function API and other resources that are integrated to your application, and then finally updating those integrations and creating any other components that are necessary. Now, typically, when we think about a complex process like this, we would use a tool like AWS CloudFormation to script out and declare all of the different resources that need to be created, and to help with the orchestration there.

However, with a serverless application, there are a lot of different resources that need to be created. So even to create a relatively simple API for instance, that has a single method with one function backing it and maybe a simple DynamoDB table, there are a number of different resources and configuration components that you would need to define inside of a CloudFormation template in order to get that application launched.

One of the main benefits of using an application framework such as the AWS Serverless Application Model (SAM) is that the code required to define all of those application components is dramatically simplified.

So now we can take a look at an example SAM template here, where we're defining a function as well as the events sources and API structure, all in a few lines of code. So, compared to the previous CloudFormation template that would've taken potentially hundreds of lines to define our application, we can now do the same thing in much, much less code. It makes it more maintainable and easier to develop and scale overall as you build larger and larger applications.

So, let's talk a little bit more about AWS SAM, which is an example of one of these application frameworks. AWS SAM provides a CLI that allows you to easily package and deploy your applications. The first step in packaging a new application is to run the SAM package command. That command is going to take all of the function code or compiled binaries within your application, create a zip archive that's ready to be deployed to Lambda, and upload that to Amazon S3.

It's then going to modify the template definition that you have to update the code uri from a local system path to the S3 path that's been created by the tool in the previous step. So now, instead of you being responsible for zipping and packaging this application, the tool itself is automating all of that process for you.

Once you've created a package template using the SAM CLI, it can then be deployed using the AWS CloudFormation service. So, this allows us to simplify the overall deployment process we looked at previously to two simple CLI commands. And now we can manage our application deployment across multiple accounts and environments easily and repeatably in order to provide an automated deployment mechanism.

So now that we have a good mechanism for packaging and deploying applications, let's talk about how you should be organizing your application code into a source code repository. Oftentimes customers struggle to decide how many functions should live within a single repository. On the one hand, you could put a single function inside of an individual repository and create a new repository for every single individual Lambda function that you create. Or you could put all of the functions that you build into a single source code repository. However, both of these options have drawbacks and really require a different mindset when you're thinking about how to organize the repositories.

Instead of being focused on individual functions, think about how your application is divided into services. A service should be comprised of one or more functions, along with all of the other AWS services, and resources necessary for that particular piece of functionality to work.

Each of those services can then be defined in an individual template and stored in a single repository. This way you have a separate repository for every service but still have multiple Lambda functions in each one of your repositories.

There are a couple of different ways you can approach providing developers with a dedicated sandbox environment. On the one hand, you can create separate accounts for each developer. This is typically the most flexible and provides the best isolation between developers. However, there is some overhead that you need to be aware of in terms of your ability to secure and monitor all of these different accounts. Assuming your organization already has the infrastructure in place to create and manage multiple AWS accounts effectively, this is probably the best way to go.

On the other hand, you can use a single shared development account that all developers use to deploy multiple stacks into. The nice thing about using a framework like we discussed in the previous section, is that each developer can deploy the same code multiple times, using something like AWS SAM and simply create multiple stacks within the same environment and test different versions of the code side by side.

Manual:

TEST AND DEBUGGING SERVERLESS APPLICATION

Demystifying Amazon ECS: A Hands-On Guide to Container Orchestration

S Uma Shankar Reddy — Wed, 12 Aug 2026 07:54:43 +0000

As I continue to dive deeper into backend development and cloud infrastructure, I've realized that understanding how to effectively deploy and manage containers is a game-changer. Mastering cloud orchestration tools is also a huge differentiator for fresh graduates stepping into the fast-paced tech industry. Recently, I completed a comprehensive lab on Amazon Elastic Container Service (ECS), and I want to share a walkthrough of that experience.

If you are familiar with Docker and basic networking (like TCP ports and Load Balancers), this guide will help you understand how AWS manages containerized applications at scale.

Here are a few snapshots from the lab environment to give you an idea of the interface and objectives:

The Architecture Overview
Before deploying anything, it's crucial to understand the environment. For this walkthrough, the foundational infrastructure was already provisioned.

Here is the architecture diagram of the environment we are working with:

Key Components:

Amazon VPC: Configured with two public subnets across separate Availability Zones for high availability.

Network Load Balancer (NLB): Routes external internet traffic to our containers.

Auto Scaling Group: Manages the underlying EC2 instances that will host our containers.

Amazon ECS Cluster: The logical grouping of our EC2 instances and tasks.

Step 1: Registering a Task Definition
In ECS, a Task Definition acts as the blueprint for your application. It’s a JSON file that tells ECS exactly how to run your Docker container, specifying details like CPU/memory allocation, port mappings, and volume mounts.

For this lab, I created a task definition family named yourApp-demo. Using a JSON configuration, I defined two containers:

simple-app: Uses the httpd:2.4 image, maps port 80, and mounts a shared volume to the Apache document root.

busybox: Uses a basic busybox image and runs a shell script to continuously generate an index.html file (saying "Congratulations!") into that shared volume.

This setup perfectly demonstrates how sidecar containers can interact via shared volumes.

Step 2: Creating an ECS Service
With the blueprint ready, the next step is to actually run it. An ECS Service ensures that your desired number of tasks are constantly running and automatically replaces any that fail.

Here is how I configured the service:

Service Name: myFirstService

Launch Type: EC2 (I opted for EC2 over Fargate, meaning the tasks run on instances we manage via the Auto Scaling Group).

Service Type: Replica (Maintains a specific number of instances; I started with a desired task count of 1).

Load Balancing: Connected to the pre-provisioned Network Load Balancer on port 80 to expose the app to the internet.

After waiting a few minutes for the deployment to complete, I grabbed the NLB's DNS name, pasted it into my browser, and successfully viewed the "Congratulations!" sample app page!

Step 3: Zero-Downtime Application Updates
One of the most powerful features of ECS is its ability to handle rolling updates smoothly. If you need to push a new version of your backend code, you don't want your users to experience downtime.

To test this, I simulated an application update:

Created a New Revision: I duplicated the original task definition but tweaked the shell script in the busybox container to output "Thank You!" instead of "Congratulations!".

Updated the Service: I navigated back to myFirstService and updated it to use the (LATEST) revision of the task definition.

What happens behind the scenes?
ECS gracefully spins up a new task with the updated definition. Once it registers as healthy, ECS drains the connections from the old task and shuts it down. Refreshing the browser seamlessly revealed the new "Thank You!" message without any service interruption.

Step 4: Scaling the Service Capacity
Handling traffic spikes is a core requirement for modern applications. ECS makes dynamic scaling incredibly straightforward.

To scale up:

I updated myFirstService again.

Changed the Desired tasks from 1 to 2.

By checking the deployment events, I could watch the ECS scheduler spring into action, provisioning a second task and distributing it appropriately across the cluster to ensure high availability. If traffic were to drop, scaling down is just as easy—ECS would gracefully terminate the excess tasks to save resources.

Final Thoughts
Stepping through this lab provided a fantastic, practical look at how Amazon ECS bridges the gap between raw Docker containers and enterprise-grade deployment. By mastering Task Definitions, Services, Rolling Updates, and Scaling, building a robust, highly available backend becomes a much more manageable reality.

If you're looking to automate this further in a production environment, exploring the underlying AWS CloudFormation templates used to build this architecture is a great next step!

i wanted to know if i can additionally change the code and costumize it so,
This JSON code is an Amazon Elastic Container Service (ECS) Task Definition. Think of it as a blueprint that tells AWS exactly how to run and configure your application’s Docker containers.

What makes this specific code interesting is that it perfectly demonstrates the Sidecar Pattern. Instead of putting everything into one massive container, it splits the workload between two containers that work together and share a storage volume.

Here is a breakdown of how it works and how you can customize it for your own projects.

🔍 Deconstructing the Code

1. The Main Server (`simple-app`)

The Job: This container is running an Apache HTTP web server ("image": "httpd:2.4").
Networking: It maps port 80 on the host to port 80 on the container (portMappings), which is the standard port for web traffic.
Storage: It mounts a volume named my-vol to the /usr/local/apache2/htdocs directory. This is the exact folder where Apache looks for files to serve to visitors.

2. The Sidekick (`busybox`)

The Job: This container uses a lightweight Linux image ("image": "busybox"). It doesn't serve web traffic; its only job is to run a script in the background.
The Script: The command section contains a shell script loop that continuously writes an HTML file—complete with a "Congratulations!" message and the current date/time—and saves it as index.html.
The Connection: Notice the "volumesFrom" block? It connects to the simple-app container's volume. By writing that index.html file into the shared space, the Apache server automatically serves it to anyone who visits the website.

🛠️ How to Customize It

You can modify this JSON to fit almost any architecture. Here are a few ways to tailor it:

Swap the Web Server

If you prefer a different web server, you can easily change the image in the simple-app definition. For example, you could swap "image": "httpd:2.4" to "image": "nginx:latest". You would just need to update the containerPath to Nginx's default web directory (/usr/share/nginx/html).

Deploy a Custom Backend

If you are pushing further into backend development, you probably won't be using a shell script to generate static HTML. You can completely replace this dual-container setup with a single container running your own code.

Change the "image" to point to your own Docker image hosted on Amazon ECR or Docker Hub (e.g., a Python container running a Django or FastAPI backend).
Remove the busybox container entirely.
Update the containerPort to match whatever port your backend framework listens on (like 8000 or 5000).

Adjust Compute Resources

Right now, the containers are allocated very few resources ("memory": 300, "cpu": 10). If your application does heavy data processing, you will need to scale these up.

CPU: Measured in CPU units (1024 units = 1 vCPU). You might bump this to 256 or 512.
Memory: Measured in MiB. You could increase this to 512 or 1024.

Add Environment Variables

Real-world applications usually need configuration data, like database passwords or API keys. You can inject these by filling out the currently empty "environment": [] array:

"environment": [
  {"name": "DATABASE_URL", "value": "your_db_connection_string"},
  {"name": "ENVIRONMENT", "value": "production"}
]

CyberArena – Interactive Cyber Security Simulation & Threat Analysis Platform

S Uma Shankar Reddy — Sat, 23 May 2026 15:03:44 +0000

Excited to share my latest project — CyberArena, an interactive Cyber Security Simulation & Threat Analysis Platform built using Python, Flask, SQLite, Docker, HTML/CSS, and JavaScript.

🔐 Features include:
• AI-based Threat Analyzer
• Phishing Simulation
• Base64 Payload Analysis
• RSA Encryption Demo
• Steganography Detection
• Leaderboard & Gamification System
• Responsive Cyberpunk Dashboard UI

This project helped me strengthen my understanding of:
✔ Cybersecurity concepts
✔ Threat analysis workflows
✔ Authentication systems
✔ Python backend development
✔ Docker deployment
✔ Responsive UI design

The platform is inspired by real-world SOC Analyst and Cyber Security Analyst workflows, including phishing detection, suspicious activity analysis, and security reporting.

🚀 Live Demo:
https://cyberarena-interactive-cyber-attack.onrender.com/

💻 GitHub:
https://github.com/omu47/CyberArena-Interactive-Cyber-Attack-Simulation-Threat-Analysis-Platform

Currently continuing to scale the project with plans for SIEM-style monitoring, PostgreSQL, Kafka, Kubernetes, and advanced AI-powered threat intelligence features.

Will really love to connect and if you want to contribute please do dm , don't waste time in thinking

Building ThreatPulse IDS: An AI-Powered Intrusion Detection System

S Uma Shankar Reddy — Wed, 20 May 2026 14:26:52 +0000

Late at night, while most people scroll through social media, millions of unseen packets travel silently across networks every second.

Some are harmless.
Some carry attacks.

That thought made me curious:
“How do cybersecurity systems actually detect threats in real time?”

So I decided to stop just reading about cybersecurity…
and build something real.

That’s how ThreatPulse IDS started.

At first, it was just a small Python script trying to capture packets using Scapy. Then came errors, crashes, threading problems, Windows packet sniffing issues, Npcap setup struggles, broken Flask reloads, database redesigns, and endless debugging sessions.

But slowly, the project evolved.

I built a system that can monitor live TCP, UDP, and ICMP traffic, detect DDoS-like behavior, identify port scans, flag suspicious IPs, and even use Machine Learning to detect anomalous traffic patterns using Isolation Forest.

Then I connected everything to a real-time SOC-style dashboard using Flask-SocketIO, added SQLite storage for persistent monitoring, created live charts, alert systems, and automated PDF security reports.

What started as curiosity became a fully working AI-powered Intrusion Detection System.

This project taught me something important:

Cybersecurity is not just about tools.
It’s about understanding behavior, patterns, networks, and building systems that can react before humans even notice something is wrong.

ThreatPulse IDS is still growing.
Next steps include GeoIP tracking, SIEM integration, threat intelligence feeds, Docker deployment, and advanced analytics.

But this project already represents something bigger for me:
proof that learning by building is the fastest way to grow.

From raw packets…
to intelligent threat detection.
click to view