Whenever I came across the word serverless, I always had the same question.
If there are no servers... where does the code actually run?
I knew the term, but I had never really understood what it meant.
Yesterday, I attended a Session - Serverless Applications with AWS Lambda by Aditya Dubey as part of the AWS Summer Builder Cohort 2026, and I think this was one of those sessions where things started making sense instead of just adding another definition to my notes.
The first thing that surprised me...
Before this session, somewhere in my mind I thought that building an application always meant worrying about servers.
Where will I deploy it?
How will it scale?
What if traffic suddenly increases?
But Lambda changes that conversation.
Instead of thinking about the infrastructure first, it lets you focus on what your code is supposed to do.
That shift in perspective was probably my biggest takeaway.
Watching it happen made a difference
I've watched tutorials before, but seeing a Lambda function being created, deployed, and tested live inside the AWS Console made everything much easier to connect.
Creating a function...
Deploying it...
Testing it...
It looked surprisingly simple.
What fascinated me wasn't the number of clicks.
It was realizing how much work AWS was handling behind the scenes without us even noticing.
One concept that really clicked
The explanation of event-driven execution was something I'll probably remember.
The function doesn't keep running all the time.
It simply waits until something triggers it.
A request comes in.
The function executes.
It finishes its job.
And that's it.
For some reason, I found that idea really interesting.
Maybe because it's such a different way of thinking compared to applications that are always running.
Lambda + DynamoDB finally made sense together
One thing I appreciated about the session was that it wasn't just about Lambda.
When Lambda was connected with DynamoDB, I stopped seeing them as two separate AWS services.
Instead, I started seeing a workflow.
A request comes in.
Lambda processes it.
DynamoDB stores or retrieves the data.
The response goes back.
It sounds simple, but that's exactly what helped me understand how different AWS services work together instead of independently.
Something I realized
I've noticed a pattern in the AWS sessions I've attended so far.
Every session starts with a technology.
But I somehow end up learning a different way of thinking.
Earlier, if someone mentioned AWS Lambda, I'd probably remember it as "AWS's serverless compute service."
Now I'll probably remember it as "the service that made me stop worrying about servers and start thinking about the actual problem my code is solving."
I think that's a much better way to remember it.
Looking ahead
I know this is just the beginning, and I still have so much to explore.
Questions like:
How does Lambda handle thousands of requests at the same time?
When should we use Lambda instead of EC2?
What are its limitations?
...are things I'm curious to learn next.
A big thank you to Aditya Dubey for such an engaging and beginner-friendly session, and to the AWS Summer Builder Cohort 2026 for creating learning experiences that make complex concepts feel much less intimidating.
I'm excited to keep learning, one session at a time.
Top comments (0)