Contact Me





    OR REACH ME ON

    Why I Started Looking Into Serverless Architectures

    By the end of 2023, after working with Docker and Kubernetes, I was curious about serverless architectures. I had seen AWS Lambda, Vercel, and Netlify growing in popularity, and clients started asking about “serverless” apps.

    At first, I thought serverless was just a buzzword. But after experimenting, I realized it’s a different way of thinking about deployments — one that made sense for certain kinds of projects.

    The Startup Reality

    Serverless doesn’t mean “no servers” — it means you don’t manage the servers yourself.

    Instead of provisioning EC2 instances or Kubernetes pods, you write small functions that cloud providers run on demand.

    Examples:

      • AWS Lambda

      • Google Cloud Functions

      • Vercel (serverless functions + hosting)

      • Netlify Functions

    First Serverless Function Example 

    				
					// hello.js (AWS Lambda / Netlify style)
exports.handler = async (event) => {
  return {
    statusCode: 200,
    body: JSON.stringify({ message: "Hello from Serverless!" }),
  };
};

    Deploy this function → it runs only when triggered. No server running 24/7.

    When Serverless Shined for Me

    1. Lightweight APIs → Instead of running a whole Node/Rails server, I could spin up a few Lambda functions.

    2. Scheduled Jobs → Cron-like tasks without a dedicated server.

    3. Prototypes & MVPs → Super fast to deploy with low cost.

    4. Event-driven Workflows → E.g., when a file uploads to S3, trigger a function to process it.

    Limitations I Hit

    1. Cold Starts → Functions had a small delay on first execution.
    2. Stateful Workloads → Not ideal for things like WebSockets or background jobs.
    3. Vendor Lock-in → Each provider had its own quirks.
    4. Complex Apps → Hard to manage when app grew too large.

    Lessons Learned

    • Serverless is not a replacement for everything.

    • Great for APIs, triggers, and small services.

    • Not great for monolithic apps with persistent connections.

    • Best used alongside traditional backends, not as a replacement.

    🎯 Final Thoughts

    By late 2023, I didn’t abandon Rails or Node servers for serverless. Instead, I started mixing them:

    • Rails/Node for core apps

    • Serverless for functions like file processing, email triggers, and light APIs

     It was a big shift in my mindset: serverless wasn’t just about cost  —  it was about choosing the right tool for the right workload.