DEV Community: Firdevs Akbayır

Why Top Engineers Are Moving to Serverless (and How You Can Build One with AWS)

Firdevs Akbayır — Sat, 16 Aug 2025 14:45:45 +0000

A step-by-step walkthrough to build your first production-ready serverless API with AWS Lambda and API Gateway.

Introduction

The rise of serverless computing has redefined the way we think about backend development. Instead of setting up servers, configuring runtimes, and worrying about scaling, developers can now focus entirely on writing the core business logic while the cloud provider handles everything else.

Among all the serverless platforms, AWS Lambda paired with API Gateway stands out as one of the most reliable and widely used solutions. With this combination, you can build APIs that are cost-efficient, production-ready, and capable of scaling automatically without manual intervention.

This series aims to break down the process into clear, actionable steps. In this first part, we will focus on AWS Lambda fundamentals—what it is, why it matters, and how to set up your very first function.

Why Serverless?

Traditional backend development required provisioning and maintaining servers, installing software packages, managing operating system updates, and ensuring high availability. While this approach works, it introduces overhead that slows down development and increases costs.

Serverless abstracts away this complexity. You don’t need to worry about servers, scaling policies, or infrastructure patches. Instead, you upload your code and let AWS take care of the rest. This is especially valuable for:

Startups and solo developers launching quickly
Applications with unpredictable traffic
APIs that don’t need 24/7 dedicated servers

AWS Lambda Fundamentals

AWS Lambda is the compute service that powers the serverless model on AWS. It allows you to:

Upload small units of code (functions)
Run them only when triggered by an event
Scale automatically with demand
Pay only for the execution time

Lambda functions are event-driven. They can be triggered by many sources such as:

API requests (via API Gateway)
File uploads (via S3)
Database events (via DynamoDB streams)
Scheduled tasks (via CloudWatch)

For our API, the main trigger will be API Gateway, but before we connect the two, let’s start by creating a Lambda function.

Step 1: Creating a Lambda Function

Navigate to the AWS Management Console and open the Lambda service.
Click Create function.
Choose Author from scratch.
- Give your function a name (e.g., myFirstLambda).
- Select a runtime (Python or Node.js are commonly used).
- Leave the default permissions for now.

Once the function is created, AWS will provide you with a built-in code editor. Inside, replace the default handler with something simple, such as:

def lambda_handler(event, context):
    return {
        "statusCode": 200,
        "body": "Hello from Lambda!"
    }

This code will execute whenever your Lambda function is triggered, returning a basic response.

Step 2: Testing the Function

Before connecting Lambda to an external service, you can test it directly in the AWS Console.

Click Test in the Lambda dashboard.
Provide a sample event (AWS offers templates you can use).
Run the test and verify that you receive a 200 OK response with the message.

At this point, you have successfully deployed and executed a Lambda function. However, it is still running in isolation and not yet exposed to the outside world. To turn it into a public API, we need to integrate it with API Gateway.

And this is where the real journey begins. In the next step, we will configure API Gateway, create routes, and connect them to Lambda—so that anyone can access your function through a REST endpoint.

To continue reading and follow the step-by-step deployment, check out the full article on Medium:

And this is where the real journey begins. The next step involves configuring API Gateway, creating routes, and connecting them to Lambda—so that anyone can access your function through a REST endpoint.

You can continue with the full step-by-step deployment in the complete article here:

Building a Serverless API with AWS Lambda & API Gateway (Part 1)

Deploy & Secure FastAPI with Docker on DigitalOcean (Step-by-Step)

Firdevs Akbayır — Mon, 11 Aug 2025 20:31:34 +0000

FastAPI is an insanely fast Python framework for building APIs — but getting it to production securely is where many developers struggle.
In this guide, we’ll containerize a FastAPI app, run it behind Nginx, enable HTTPS with Let’s Encrypt, and deploy it to a DigitalOcean Droplet — production-ready from day one.

By the end, you’ll have:

Portable deployment with Docker
Secure communication (HTTPS + Nginx reverse proxy)
Easy scaling for high-traffic apps

High-Level Steps

Create & SSH into a DigitalOcean Droplet
Install Docker & Docker Compose
Write a minimal FastAPI app (main.py)
Create Dockerfile for containerization
Add Nginx reverse proxy via docker-compose.yml
Configure DNS & domain
Install Certbot & enable HTTPS
Run with Gunicorn for production

Minimal Dockerfile

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

docker-compose.yml with Nginx

version: "3.8"
services:
  app:
    build: .
    container_name: fastapi_app
    restart: unless-stopped
    expose:
      - "8000"

  nginx:
    image: nginx:alpine
    container_name: nginx_proxy
    depends_on:
      - app
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
      - certbot-etc:/etc/letsencrypt
      - certbot-var:/var/www/certbot
    restart: unless-stopped

volumes:
  certbot-etc:
  certbot-var:

Full Tutorial

This is the condensed version.
For the full guide — including Nginx config, SSL setup, firewall rules, and production tweaks — read it here:

The Complete Guide to Deploying FastAPI with Docker on DigitalOcean

Question for you: How do you deploy your Python APIs in production? Share your stack in the comments!

How Cloud Storage Works Behind the Scenes (Object vs Block vs File - A Backend Developer's Guide)

Firdevs Akbayır — Wed, 06 Aug 2025 20:59:45 +0000

1. Introduction & Use Case Overview

In today’s cloud-native world, data isn’t just stored—it’s streamed, processed, replicated, and scaled across regions in milliseconds. Behind every app we use—whether it’s a video platform, a messaging service, or a SaaS dashboard—there’s a robust storage system ensuring data is available, durable, and fast.

Cloud storage isn’t one-size-fits-all. Depending on the type of data, performance requirements, and cost constraints, engineers choose between object, block, and file storage—each designed for very different use cases.

In this article, we’ll break down:

What each storage type actually is under the hood
How AWS, DigitalOcean, and other platforms implement them
Real-world design considerations for choosing the right storage layer

We begin with the most widely adopted model in the cloud era—Object Storage.

2. Object Storage: The Foundation of Cloud-Native Data

Object storage is the most scalable and cost-effective way to store unstructured data in the cloud. Unlike traditional file or block systems, object storage doesn’t use folders or file hierarchies. Instead, it stores data as objects—each containing the data itself, metadata, and a unique identifier.

Key Characteristics:

Flat namespace: No nested folders—everything lives in a "bucket".
Metadata-rich: Each object can store customizable metadata for easy retrieval.
Immutable by default: Objects aren’t updated; they’re replaced entirely.
Massive scalability: Ideal for storing millions or billions of files.

Real-World Example: AWS S3

Amazon S3 is a globally recognized object storage service known for its durability and flexibility. It stores data across multiple availability zones, ensuring high availability even during regional failures.

Amazon S3 (Simple Storage Service) is the gold standard in object storage:
Stores data across multiple Availability Zones for durability.
Offers storage classes (Standard, Glacier, etc.) for cost optimization.
Provides event-driven capabilities (e.g., trigger a Lambda when an object is uploaded).

Common Use Cases:

Static website hosting
Media storage (images, videos, audio)
Backup and disaster recovery
Log and analytics data archiving

Other Providers:

DigitalOcean Spaces: S3-compatible interface with simpler pricing.
Google Cloud Storage: Similar model, integrated with GCP services.
MinIO: An open-source, self-hosted object storage system for private clouds.

3. File Storage: Hierarchical Data Access for Collaborative Systems

File storage organizes data into directories and files—much like what users experience on their laptops or shared drives. It’s ideal for workloads that rely on hierarchical structures and need to be accessed by multiple users or applications simultaneously.

Unlike object storage (which lacks a directory system) and block storage (which offers raw performance), file storage strikes a balance between usability and shared access.

Key Characteristics

File and folder hierarchy with familiar path structures (e.g., /data/images/photo.jpg)
Shared access via standard protocols (NFS, SMB, CIFS)
Supports file-level permissions and locking for concurrent access

Real-World Example: Amazon EFS

Elastic File System (EFS) is AWS’s file storage solution.
Fully managed NFS file system that can be mounted across multiple EC2 instances.
Scales automatically with demand and offers performance & throughput modes.

Common Use Cases

Shared development environments
Content management systems (CMS)
User home directories in VDI setups
Lift-and-shift of legacy on-prem apps to the cloud

Other Providers

Azure Files: SMB support with Windows-based integrations
Google Filestore: Managed NFS service optimized for GCP
NetApp Cloud Volumes: Enterprise-grade file storage with rich features

4. Block Storage: Raw Performance for Mission-Critical Systems

Block storage breaks data into fixed-size chunks—called blocks—and stores them individually. Each block has a unique address but no metadata or structure. It's the most low-level, high-performance type of storage used in cloud computing.

Unlike file or object storage, block storage operates beneath the filesystem level, making it ideal for databases, virtual machines, and high-I/O workloads where speed and precision matter.

Key Characteristics

No hierarchy: Blocks are accessed via logical block addresses, not file paths
Ultra-fast IOPS and low latency
Requires a filesystem (e.g., ext4, NTFS) to interpret stored data
Best suited for single-VM or single-app access patterns

Real-World Example: Amazon EBS

Elastic Block Store (EBS) offers persistent block volumes for EC2
Supports SSD (gp3, io2) and HDD (st1, sc1) volume types
Enables snapshots, encryption, and automated backups

Common Use Cases

Relational and NoSQL databases (e.g., MySQL, PostgreSQL, MongoDB)
Virtual machines and container storage
Transaction-heavy applications
File systems that need low-level disk control

Other Providers

DigitalOcean Volumes: Simple block storage volumes attachable to droplets
Google Persistent Disks: Durable block storage for GCE with snapshot support
Linode Block Storage: High-availability volumes mountable to multiple instances

5. Comparing Storage Types: Object vs Block vs File

Choosing the right storage backend is about trade-offs. Each type excels in different dimensions—scalability, performance, or simplicity. Here's a high-level comparison:

Feature	Object Storage	Block Storage	File Storage
Structure	Flat (buckets)	Raw blocks	Hierarchical (folders)
Metadata Support	Rich, customizable	None	Basic (file metadata)
Performance	Moderate	High (low latency)	Medium
Scalability	Massive (petabytes+)	Limited to volume size	Scales with effort
Access	HTTP API (REST/S3)	Mounted to instance	Shared over network
Use Case Suitability	Static assets, backups	Databases, VMs	Shared files, home dirs
Typical Providers	AWS S3, DO Spaces	AWS EBS, GCP PD	AWS EFS, Azure Files
Protocol	RESTful APIs	iSCSI, NVMe, etc.	NFS, SMB

6. Choosing the Right Storage Model

Making the right storage decision depends on data access patterns, latency requirements, cost constraints, and deployment models.

Use Object Storage when:

You need to store large volumes of unstructured data (images, videos, logs)
You want durability and replication across regions
You're working with services like AWS S3 or DO Spaces
You can tolerate eventual consistency and REST-based access

Use Block Storage when:

You’re running high-performance workloads (e.g., MySQL, PostgreSQL, Kafka)
You need full control over the filesystem and format
Low latency and high IOPS are critical
Your application is designed to access storage as mounted volumes

Use File Storage when:

You need a shared drive across multiple VMs (like user home directories)
You’re running legacy apps expecting a traditional filesystem
Collaboration is required over a familiar file-tree structure

7. Best Practices for Scalable and Secure Cloud Storage Architecture

Making smart choices about your storage backend early on can prevent scale, cost, and performance bottlenecks. Here are some guiding principles:

Design for Scalability First

If your application faces unpredictable growth and demands internet-scale storage, object storage should be your default starting point.
Architect around storage classes (e.g., S3 Standard vs Glacier) to optimize cost.

Prioritize Data Access Patterns

Block storage for transactional systems (databases, boot volumes).
Object storage for write-once-read-many use cases (backups, logs, media).
File storage for concurrent read-write scenarios (shared apps, dev environments).

Embrace Lifecycle Policies and Tiering

Automate transitions between hot, warm, and cold storage layers.
Use S3 lifecycle rules or DigitalOcean Spaces’ auto-deletion features.

Secure Data at Rest and in Transit

Always enable encryption (e.g., SSE-S3 or SSE-KMS on AWS).
Leverage signed URLs, IAM policies, and access scopes.

Plan for Cross-Region Redundancy

Object storage natively supports this (e.g., S3’s cross-region replication).
Block and file storage may require custom replication strategies.

Conclusion: Architecting Resilient and Cost-Effective Storage Solutions

Cloud storage isn't just about saving data—it's about designing for scale, cost-efficiency, and long-term reliability. Each storage type—object, block, and file—serves a clear purpose in modern architectures.

By understanding their trade-offs and internal mechanics, you’re better equipped to make engineering decisions that stand the test of time.

Start with your workload needs, align them with the right storage layer, and revisit your architecture as your product grows. The best cloud systems are not only fast—they're thoughtfully built from the ground up.